From ips-bounces@ietf.org Thu Sep 01 12:57:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsNH-0003Ra-9a; Thu, 01 Sep 2005 12:57:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsNF-0003RS-7V for ips@megatron.ietf.org; Thu, 01 Sep 2005 12:57:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14816 for ; Thu, 1 Sep 2005 12:57:10 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAsPD-0004wh-HL for ips@ietf.org; Thu, 01 Sep 2005 12:59:16 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id A309E8709D; Thu, 1 Sep 2005 12:57:00 -0400 (EDT) In-Reply-To: <000601c5ae66$277d0890$680115ac@elipsan.com> References: <000601c5ae66$277d0890$680115ac@elipsan.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] Discovery reinstatement Date: Thu, 1 Sep 2005 09:56:54 -0700 To: "Ken Sandars" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 'IPS' , "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1665379238==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1665379238== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--889757313" Content-Transfer-Encoding: 7bit --Apple-Mail-4--889757313 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 31, 2005, at 12:56 PM, Ken Sandars wrote: > Hi Mallikarjun, > > I like your approach to this problem. In my mind the answer to > question 1 is > a strong yes, however, I do not like the clause about Network Entity. > >> From my last posting, I restate: an initiator may not know if two >> Portals > belong to the same Network Entity. For the purposes of discovery, all > it > requires prior to establishing the discovery session is each Portal's > TCP > addressing information. > > Without a priori knowledge of which portals are in the same Network > Entity, > it would be difficult for an initiator to deterministically know if > starting > a discovery session to Portal Y is going to reinstate its existing > discovery > session on Portal X. > > Of the four possibilities you propose, I agree that II is on the path > to > predictable behaviour. However, I suggest the decision to reinstate a > Discovery session should be based upon matching the tuple > InitiatorName + > ISID + servicing iSCSI Portal. Hence a Network Entity with four > Portals may > carry four discovery sessions simultaneously from the one > InitiatorName+ISID > pair (one per Portal). Your proposal basically is Option B, or Option III. :-) Take care, Bill --Apple-Mail-4--889757313 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDFzLbDJT2Egh26K0RApfbAKCYW/F18le/9YXSfuoYqcRR/hxPJgCgg0RM CtiF1P5lwYFhDqQfoOYSbW0= =hgoC -----END PGP SIGNATURE----- --Apple-Mail-4--889757313-- --===============1665379238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1665379238==-- From ips-bounces@ietf.org Thu Sep 01 13:09:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsYl-00032c-Qb; Thu, 01 Sep 2005 13:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsYj-00030L-Nv for ips@megatron.ietf.org; Thu, 01 Sep 2005 13:09:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15377 for ; Thu, 1 Sep 2005 13:09:02 -0400 (EDT) Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAsag-0005Hj-Ad for ips@ietf.org; Thu, 01 Sep 2005 13:11:09 -0400 Received: from hq-ex-4.corp.brocade.com (hq-ex-4 [192.168.38.93]) by blasphemy.brocade.com (Postfix) with ESMTP id 62DC514312; Thu, 1 Sep 2005 10:08:40 -0700 (PDT) Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by hq-ex-4.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Sep 2005 10:08:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Discovery reinstatement Date: Thu, 1 Sep 2005 10:08:40 -0700 Message-ID: Thread-Topic: [Ips] Discovery reinstatement Thread-Index: AcWuZuAX8NURBm09T+SG1dATqKiaSwAr4Jag From: "John Hufferd" To: "Mallikarjun C." , "IPS" X-OriginalArrivalTime: 01 Sep 2005 17:08:40.0192 (UTC) FILETIME=[CC9DA800:01C5AF17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I guess I do not understand why anyone cares about the reinstatement of a discovery session. It was suppose to be simple and straight forward. I don't thing any of us thought that the discovery session was so important that it needed reinstatement. It does a very simple thing, has no direct relationship to any application, and has no direct impact on the operation of a SCSI I/O command. Further, it is easy enough to just restart without having any state from a previous connection. I see no reason to make this complicated and then have the implementers bother with add'l lines of code, and tests, including the interoperation test. The reinstatement was intended for normal connections that could be carrying SCSI I/O operations, and we wanted to avoid the SCSI level error recovery. I suggest that we keep this discovery stuff real simple and just have the initiator restart the Discovery session (from Scratch) if a problem occurs. I also think that if for some reason an installation needs a more robust discovery process, that they use something like iSNS. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Ken Sandars Sent: Wednesday, August 31, 2005 12:57 PM To: 'Mallikarjun C.'; 'IPS' Subject: RE: [Ips] Discovery reinstatement Hi Mallikarjun, I like your approach to this problem. In my mind the answer to question 1 is a strong yes, however, I do not like the clause about Network Entity. >From my last posting, I restate: an initiator may not know if two Portals belong to the same Network Entity. For the purposes of discovery, all it requires prior to establishing the discovery session is each Portal's TCP addressing information. Without a priori knowledge of which portals are in the same Network Entity, it would be difficult for an initiator to deterministically know if starting a discovery session to Portal Y is going to reinstate its existing discovery session on Portal X. Of the four possibilities you propose, I agree that II is on the path to predictable behaviour. However, I suggest the decision to reinstate a Discovery session should be based upon matching the tuple InitiatorName + ISID + servicing iSCSI Portal. Hence a Network Entity with four Portals may carry four discovery sessions simultaneously from the one InitiatorName+ISID pair (one per Portal). Thanks, Ken=20 Ken Sandars Adaptec UK > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Mallikarjun C. > Sent: 24 August 2005 21:04 > To: IPS > Subject: [Ips] Discovery reinstatement >=20 >=20 > I spent sometime studying previous email threads on this=20 > topic and gave=20 > the topic some thought. My current thinking and rationale is written=20 > below, I hope we'll arrive at a consensus on this topic this=20 > time...... >=20 > In short, I'm leaning towards not saying anything on discovery=20 > reinstatement in the Implementer's guide, but still open to being=20 > persuaded otherwise. Sorry it's a long note. >=20 > [Options: >=20 > A. TPGTs are always Node-scoped. If Node name isn't specified in the=20 > discovery Login Request PDU, TPGT is meaningless and can't be=20 > inferred=20 > (or inferred to be invalid). >=20 > B. TPGTs are always Node-scoped. If Node name isn't specified in the=20 > discovery Login Request PDU, a special "No-Name" iSCSI Node=20 > is implied.=20 > This No-Name iSCSI Node has its own TPGT numbering space -=20 > one tag for=20 > each physically possible portal group - and thus the TPGT can=20 > be inferred. ] >=20 >=20 > Question 1: > Is it desirable that an initiator precisely know in advance when a new > discovery session might reinstate an existing discovery session (with > the same Network Entity)? >=20 > Yes (based on the plugfest feedback), so let's analyze what=20 > this leads=20 > us to. If I got this wrong, feel free to reset me (especially to Bob=20 > Russell). >=20 > If the answer is no, then the whole discussion is moot (jump=20 > down to the > conclusions). >=20 > Question 2: > If so, how would the initiator deterministically know what reinstates > what? >=20 > Option A: > Assuming a fixed InitiatorName and ISID pair, a new no-named discovery > session will reinstate an old no-named discovery session if the > following is met: > (1) servicing iSCSI Portal (for the new session) is hosted by the > same Network Entity as that of the existing session. >=20 > Option B: > Assuming a fixed InitiatorName and ISID pair, a new no-named discovery > session will reinstate an old no-named discovery session if the > following are met: > (1) servicing iSCSI Portal (for the new session) is hosted by the > same Network Entity as that of the existing session, and, >=20 > (2) TPGT of the servicing iSCSI Portal (for the new session) matches > that of the existing session. >=20 > Question 3: > Can the conditions for each option be met? >=20 > Condition (1) can be met if we assume that the initiator has a > (non-iSCSI) way of discovering that two IP addresses are hosted > by one remote system (i.e. iSCSI Network Entity). >=20 > Condition (2) for realizing Option B however cannot be met=20 > because TPGT > is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the > absence of a node name nor a way to communicate them to the initiator > apriori. Besides, there's a bootstrapping problem in that a discovery > session is needed to find out TPGT associations. >=20 > So I believe condition (2) cannot be met, and thus do not see a way to > support Option.B *given* the desire that the initiator=20 > deterministically > predict session reinstatement in advance (answer to Question.1). >=20 >=20 > To summarize: >=20 > I see four possibilities (in decreasing order of my preference): >=20 > I. We reject the assertion that initiator should be able to > deterministically predict session reinstatement. So say > nothing about this topic in the Implementer's guide. >=20 > II. We accept the assertion. So mandate Option A in Implementer's > guide. >=20 > III.We "semi-accept" the assertion by saying that the initiator cannot > predict reinstatement in advance but will know why a=20 > reinstatement > happened post-fact (because the new session returned the=20 > same TPGT > as did an existing no-named session). So mandate Option B in > Implementer's guide. >=20 > IV. We reject the assertion. Specify both Option A and=20 > Option B in the > Implementer's guide. And leave it to implementer's discretion. >=20 > I am personally fine with either I or II but not motivated to=20 > go to III > because it does not satisfy the "predict in advance" desire even > while it requires enhancements/changes to RFC 3720 (and by=20 > extension, to > some existing implementations): > a) allow a No-Name target node (i.e. a node that maps 1-to-1 > with Network Entity) > b) explicitly allow a TPGT numbering space for a No-Name target > c) mandate returning TPGT on no-named discovery sessions. > d) deal with second-order questions such as: shouldn't the > No-Name target information be returned in SendTargets response? > how about target port names for No-Name target node? .... >=20 > The net is that I see very little ROI in III. >=20 > I again see little ROI in IV. > --=20 > Mallikarjun >=20 > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 01 13:24:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsnL-0001wK-Uj; Thu, 01 Sep 2005 13:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAsnJ-0001wF-I1 for ips@megatron.ietf.org; Thu, 01 Sep 2005 13:24:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16178 for ; Thu, 1 Sep 2005 13:24:06 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAspI-0005kW-37 for ips@ietf.org; Thu, 01 Sep 2005 13:26:13 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j81HNuil019373 for ; Thu, 1 Sep 2005 13:23:57 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j81HNuje019368; Thu, 1 Sep 2005 13:23:56 -0400 Received: from pkoning.equallogic.com ([172.16.1.163]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 13:23:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17175.14634.927438.835558@gargle.gargle.HOWL> Date: Thu, 1 Sep 2005 13:23:54 -0400 From: Paul Koning To: jhufferd@Brocade.COM Subject: RE: [Ips] Discovery reinstatement References: X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 01 Sep 2005 17:23:56.0588 (UTC) FILETIME=[EED496C0:01C5AF19] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org, cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "John" == John Hufferd writes: John> I guess I do not understand why anyone cares about the John> reinstatement of a discovery session. It was suppose to be John> simple and straight forward. ... John> I suggest that we keep this discovery stuff real simple and John> just have the initiator restart the Discovery session (from John> Scratch) if a problem occurs. I agree. It seems that we're spending a lot of energy spelling out a pile of special case rules for something that isn't needed in the first place. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 01 13:58:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtK8-0001Zj-45; Thu, 01 Sep 2005 13:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtK6-0001Ze-SJ for ips@megatron.ietf.org; Thu, 01 Sep 2005 13:58:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17279 for ; Thu, 1 Sep 2005 13:57:59 -0400 (EDT) From: pat_thaler@agilent.com Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtM6-0006c6-FR for ips@ietf.org; Thu, 01 Sep 2005 14:00:07 -0400 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id DA4AB27003 for ; Thu, 1 Sep 2005 11:57:50 -0600 (MDT) Received: from wlvdvs01.lvld.agilent.com (wlvdvs01.lvld.agilent.com [148.5.6.4]) by relcos1.cos.agilent.com (Postfix) with ESMTP id B07003CE for ; Thu, 1 Sep 2005 11:57:50 -0600 (MDT) Received: from wcosbh01.cos.agilent.com ([130.29.152.125]) by wlvdvs01.lvld.agilent.com with InterScan Messaging Security Suite; Thu, 01 Sep 2005 11:57:49 -0600 Received: from wcosmb05.cos.agilent.com ([130.29.152.72]) by wcosbh01.cos.agilent.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Sep 2005 11:57:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Discovery reinstatement Date: Thu, 1 Sep 2005 11:57:48 -0600 Message-ID: <9418406DEC3B8A4BBDB1B87291D851AFD8C7F2@wcosmb05.cos.agilent.com> Thread-Topic: [Ips] Discovery reinstatement Thread-Index: AcWuZuAX8NURBm09T+SG1dATqKiaSwAr4JagAAIMjcA= To: , , X-OriginalArrivalTime: 01 Sep 2005 17:57:49.0022 (UTC) FILETIME=[AA4167E0:01C5AF1E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org John, I've been thinking the same thing. Pat -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = John Hufferd Sent: Thursday, 01 September, 2005 10:09 AM To: Mallikarjun C.; IPS Subject: RE: [Ips] Discovery reinstatement I guess I do not understand why anyone cares about the reinstatement of a discovery session. It was suppose to be simple and straight forward. I don't thing any of us thought that the discovery session was so important that it needed reinstatement. It does a very simple thing, has no direct relationship to any application, and has no direct impact on the operation of a SCSI I/O command. Further, it is easy enough to just restart without having any state from a previous connection. I see no reason to make this complicated and then have the implementers bother with add'l lines of code, and tests, including the interoperation test. The reinstatement was intended for normal connections that could be carrying SCSI I/O operations, and we wanted to avoid the SCSI level error recovery. I suggest that we keep this discovery stuff real simple and just have the initiator restart the Discovery session (from Scratch) if a problem occurs. I also think that if for some reason an installation needs a more robust discovery process, that they use something like iSNS. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Ken Sandars Sent: Wednesday, August 31, 2005 12:57 PM To: 'Mallikarjun C.'; 'IPS' Subject: RE: [Ips] Discovery reinstatement Hi Mallikarjun, I like your approach to this problem. In my mind the answer to question 1 is a strong yes, however, I do not like the clause about Network Entity. >From my last posting, I restate: an initiator may not know if two Portals belong to the same Network Entity. For the purposes of discovery, all it requires prior to establishing the discovery session is each Portal's TCP addressing information. Without a priori knowledge of which portals are in the same Network Entity, it would be difficult for an initiator to deterministically know if starting a discovery session to Portal Y is going to reinstate its existing discovery session on Portal X. Of the four possibilities you propose, I agree that II is on the path to predictable behaviour. However, I suggest the decision to reinstate a Discovery session should be based upon matching the tuple InitiatorName + ISID + servicing iSCSI Portal. Hence a Network Entity with four Portals may carry four discovery sessions simultaneously from the one InitiatorName+ISID pair (one per Portal). Thanks, Ken=20 Ken Sandars Adaptec UK > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Mallikarjun C. > Sent: 24 August 2005 21:04 > To: IPS > Subject: [Ips] Discovery reinstatement >=20 >=20 > I spent sometime studying previous email threads on this=20 > topic and gave=20 > the topic some thought. My current thinking and rationale is written=20 > below, I hope we'll arrive at a consensus on this topic this=20 > time...... >=20 > In short, I'm leaning towards not saying anything on discovery=20 > reinstatement in the Implementer's guide, but still open to being=20 > persuaded otherwise. Sorry it's a long note. >=20 > [Options: >=20 > A. TPGTs are always Node-scoped. If Node name isn't specified in the=20 > discovery Login Request PDU, TPGT is meaningless and can't be=20 > inferred=20 > (or inferred to be invalid). >=20 > B. TPGTs are always Node-scoped. If Node name isn't specified in the=20 > discovery Login Request PDU, a special "No-Name" iSCSI Node=20 > is implied.=20 > This No-Name iSCSI Node has its own TPGT numbering space -=20 > one tag for=20 > each physically possible portal group - and thus the TPGT can=20 > be inferred. ] >=20 >=20 > Question 1: > Is it desirable that an initiator precisely know in advance when a new > discovery session might reinstate an existing discovery session (with > the same Network Entity)? >=20 > Yes (based on the plugfest feedback), so let's analyze what=20 > this leads=20 > us to. If I got this wrong, feel free to reset me (especially to Bob=20 > Russell). >=20 > If the answer is no, then the whole discussion is moot (jump=20 > down to the > conclusions). >=20 > Question 2: > If so, how would the initiator deterministically know what reinstates > what? >=20 > Option A: > Assuming a fixed InitiatorName and ISID pair, a new no-named discovery > session will reinstate an old no-named discovery session if the > following is met: > (1) servicing iSCSI Portal (for the new session) is hosted by the > same Network Entity as that of the existing session. >=20 > Option B: > Assuming a fixed InitiatorName and ISID pair, a new no-named discovery > session will reinstate an old no-named discovery session if the > following are met: > (1) servicing iSCSI Portal (for the new session) is hosted by the > same Network Entity as that of the existing session, and, >=20 > (2) TPGT of the servicing iSCSI Portal (for the new session) matches > that of the existing session. >=20 > Question 3: > Can the conditions for each option be met? >=20 > Condition (1) can be met if we assume that the initiator has a > (non-iSCSI) way of discovering that two IP addresses are hosted > by one remote system (i.e. iSCSI Network Entity). >=20 > Condition (2) for realizing Option B however cannot be met=20 > because TPGT > is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the > absence of a node name nor a way to communicate them to the initiator > apriori. Besides, there's a bootstrapping problem in that a discovery > session is needed to find out TPGT associations. >=20 > So I believe condition (2) cannot be met, and thus do not see a way to > support Option.B *given* the desire that the initiator=20 > deterministically > predict session reinstatement in advance (answer to Question.1). >=20 >=20 > To summarize: >=20 > I see four possibilities (in decreasing order of my preference): >=20 > I. We reject the assertion that initiator should be able to > deterministically predict session reinstatement. So say > nothing about this topic in the Implementer's guide. >=20 > II. We accept the assertion. So mandate Option A in Implementer's > guide. >=20 > III.We "semi-accept" the assertion by saying that the initiator cannot > predict reinstatement in advance but will know why a=20 > reinstatement > happened post-fact (because the new session returned the=20 > same TPGT > as did an existing no-named session). So mandate Option B in > Implementer's guide. >=20 > IV. We reject the assertion. Specify both Option A and=20 > Option B in the > Implementer's guide. And leave it to implementer's discretion. >=20 > I am personally fine with either I or II but not motivated to=20 > go to III > because it does not satisfy the "predict in advance" desire even > while it requires enhancements/changes to RFC 3720 (and by=20 > extension, to > some existing implementations): > a) allow a No-Name target node (i.e. a node that maps 1-to-1 > with Network Entity) > b) explicitly allow a TPGT numbering space for a No-Name target > c) mandate returning TPGT on no-named discovery sessions. > d) deal with second-order questions such as: shouldn't the > No-Name target information be returned in SendTargets response? > how about target port names for No-Name target node? .... >=20 > The net is that I see very little ROI in III. >=20 > I again see little ROI in IV. > --=20 > Mallikarjun >=20 > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 01 14:50:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAu9H-0005cL-5f; Thu, 01 Sep 2005 14:50:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAu9G-0005cG-3p for ips@megatron.ietf.org; Thu, 01 Sep 2005 14:50:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22638 for ; Thu, 1 Sep 2005 14:50:50 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAuBF-0000rY-CH for ips@ietf.org; Thu, 01 Sep 2005 14:52:58 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 332E68709A; Thu, 1 Sep 2005 14:50:44 -0400 (EDT) In-Reply-To: <17175.14634.927438.835558@gargle.gargle.HOWL> References: <17175.14634.927438.835558@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <4df70d6af3df024cec12e11d4549868d@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery reinstatement Date: Thu, 1 Sep 2005 11:50:35 -0700 To: jhufferd@Brocade.COM, Paul Koning X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: 'IPS' , "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0109359910==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0109359910== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5--882936192" Content-Transfer-Encoding: 7bit --Apple-Mail-5--882936192 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 1, 2005, at 10:23 AM, Paul Koning wrote: >>>>>> "John" == John Hufferd writes: > > John> I guess I do not understand why anyone cares about the > John> reinstatement of a discovery session. It was suppose to be > John> simple and straight forward. ... John, I was about to respond to you. Paul had asked me the same thing off-list too. > John> I suggest that we keep this discovery stuff real simple and > John> just have the initiator restart the Discovery session (from > John> Scratch) if a problem occurs. > > I agree. It seems that we're spending a lot of energy spelling out a > pile of special case rules for something that isn't needed in the > first place. Depends on how the target is implemented. If discovery sessions are different objects in the target from normal sessions, you're right. We're talking about a lot of complexity. However if the target implemented "sessions" and had session type as an attribute, then this discussion makes more sense, and this discussion actually is talking about making things simpler. Really. :-) A few years ago we had the discussion about what to do with no-target discovery sessions. The decision then was that they follow the ISID rule, with a "" target name. And that made life simpler and easier. Sessions always follow the ISID rule and session type is just an attribute. It may not seem like it to an initiator, but that really can make life easier for a target. :-) The discussion now stems from the fact that we forgot to discuss what to put in for TPGT on a no-target session. "NUL" makes sense, but has consequences based on how a target is designed; if you have a number of iSCSI processing heads, discovery sessions can trigger inter-board communication that would not be present for normal sessions. Thus it can be simpler to let targets actually put a TPGT value in when looking up the ISID tuple. So I see this discussion not as, "we really thing discovery sessions need to follow reinstatement," but more "all sessions follow the ISID rule, and as a consequence X happens." So that's why we care about session reinstatement. At this point, to make sessions not reinstate would mean breaking the ISID rule. And it'd be a real PITA. Take care, Bill --Apple-Mail-5--882936192 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDF02ADJT2Egh26K0RAnT2AJ9GlawVNj5S74vMsYLyVHOzDaD9aQCdGcVU u4JJtjsY+qkuyg6cy2gkLeg= =bGlZ -----END PGP SIGNATURE----- --Apple-Mail-5--882936192-- --===============0109359910== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0109359910==-- From ips-bounces@ietf.org Thu Sep 01 21:57:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0oN-0006vO-NY; Thu, 01 Sep 2005 21:57:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0oL-0006vB-Im for ips@megatron.ietf.org; Thu, 01 Sep 2005 21:57:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12076 for ; Thu, 1 Sep 2005 21:57:43 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB0qN-0004og-JB for ips@ietf.org; Thu, 01 Sep 2005 21:59:53 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id BCE1A8709D; Thu, 1 Sep 2005 21:57:29 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <8b09edb994d634c864c6fa5ac0b4bcdf@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery reinstatement Date: Thu, 1 Sep 2005 18:57:21 -0700 To: "John Hufferd" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: IPS , "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0960399501==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0960399501== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8--857330083" Content-Transfer-Encoding: 7bit --Apple-Mail-8--857330083 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I just noticed one thing that I think is a misunderstanding that is rather key to the discussion. :-) On Sep 1, 2005, at 10:08 AM, John Hufferd wrote: > I guess I do not understand why anyone cares about the reinstatement of > a discovery session. It was suppose to be simple and straight forward. > I don't thing any of us thought that the discovery session was so > important that it needed reinstatement. It does a very simple thing, > has no direct relationship to any application, and has no direct impact > on the operation of a SCSI I/O command. Further, it is easy enough to > just restart without having any state from a previous connection. I > see > no reason to make this complicated and then have the implementers > bother > with add'l lines of code, and tests, including the interoperation test. I see something I missed in reading the spec. In all of my readings of the spec, I had assumed that we would always be at ERL 0 for a discovery session, and I thought it was mandated in RFC 3720. Turns out I'm wrong about the mandate. Yes, I think that ERL 1 or ERL 2 reinstatement is SILLY for a discovery session, and I do not want to contemplate it. I wish we had made ErrorRecoveryLevel Irrelevant if SessionType=Discovery. Can we add that to this draft too? > The reinstatement was intended for normal connections that could be > carrying SCSI I/O operations, and we wanted to avoid the SCSI level > error recovery. As per my misunderstanding above, when I have said, "reinstatement," I mean session reinstatement a la section 6.1.4.4 of RFC 3720; I have always expected it to mean a TCP RST and target garbage collection of the old session and connection. I have never expected within-connection or between-connection recovery to apply. I also have expected all the cases we have discussed (parallel discovery) to involve a TSIH of zero, so the new connection will blow away the old one. > I suggest that we keep this discovery stuff real simple and just have > the initiator restart the Discovery session (from Scratch) if a problem > occurs. I also think that if for some reason an installation needs a > more robust discovery process, that they use something like iSNS. And I always considered calling close(2) on the old connection simple, so I felt that session reinstatement was no big deal for a discovery session. I think the main thing for interop is that if an initiator is performing parallel discovery, it can get TCP RSTs on connections when new connections end up being to the same network entity. And it should be prepared for that. Take care, Bill --Apple-Mail-8--857330083 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDF7GHDJT2Egh26K0RAuqFAKCOJicB3KVTt35lUzcexA0EIwmZ6QCcD1iE 3WgdWFQmFlhUitNyfExz2mg= =ZzTq -----END PGP SIGNATURE----- --Apple-Mail-8--857330083-- --===============0960399501== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0960399501==-- From ips-bounces@ietf.org Thu Sep 01 22:44:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB1Xk-000330-Gp; Thu, 01 Sep 2005 22:44:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB1Xi-00032l-8i for ips@megatron.ietf.org; Thu, 01 Sep 2005 22:44:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25321 for ; Thu, 1 Sep 2005 22:44:36 -0400 (EDT) Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB1Zm-0006Fy-Ja for ips@ietf.org; Thu, 01 Sep 2005 22:46:47 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel6.hp.com (Postfix) with ESMTP id AB656B46B for ; Thu, 1 Sep 2005 22:44:34 -0400 (EDT) Received: from [127.0.0.1] (palnai12-1218.corp.hp.com [15.244.196.194]) by rosemail.rose.hp.com (Postfix) with ESMTP id B7E8781F4 for ; Thu, 1 Sep 2005 19:41:59 -0700 (PDT) Message-ID: <4317BC94.2040405@rose.hp.com> Date: Thu, 01 Sep 2005 19:44:36 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS Subject: Re: [Ips] Discovery reinstatement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org John says: > I suggest that we keep this discovery stuff real simple Paul says: >I agree. It seems that we're spending a lot of energy spelling >out a pile of special case rules Pat says: >John, I've been thinking the same thing. Did I finally see some new WG interest in this topic? :-) (Thanks John!) Actually, I very much agree with the sentiments. However, considering the list bandwidth spent over the last 2 years or so on this topic, seems to me that future bandwidth savings can be realized only by saying something definitive in the new guide. > The reinstatement was intended for normal connections that could be > carrying SCSI I/O operations, and we wanted to avoid the SCSI level > error recovery. Not really, session reinstatement is the antithesis of recovery. >just have > the initiator restart the Discovery session (from Scratch) if a problem > occurs. I also think that if for some reason an installation needs a > more robust discovery process, that they use something like iSNS Agreed. However, that though strictly isn't the question on hand - current question pertains to the target behavior. Should a discovery session wipe out an old session with the same coordinates at the network entity level (some/several of us, myself included, think so), or at the "physical" portal group level without a node context (at least one of us thinks so), or at the "physical" portal level without a node context (at least one of us thinks so)? I'm as eager as everyone to put this issue behind and move on, quick WG feedback certainly helps. Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com John Hufferd wrote: > I guess I do not understand why anyone cares about the reinstatement of > a discovery session. It was suppose to be simple and straight forward. > I don't thing any of us thought that the discovery session was so > important that it needed reinstatement. It does a very simple thing, > has no direct relationship to any application, and has no direct impact > on the operation of a SCSI I/O command. Further, it is easy enough to > just restart without having any state from a previous connection. I see > no reason to make this complicated and then have the implementers bother > with add'l lines of code, and tests, including the interoperation test. > > The reinstatement was intended for normal connections that could be > carrying SCSI I/O operations, and we wanted to avoid the SCSI level > error recovery. > > I suggest that we keep this discovery stuff real simple and just have > the initiator restart the Discovery session (from Scratch) if a problem > occurs. I also think that if for some reason an installation needs a > more robust discovery process, that they use something like iSNS. > > . > . > . > John L Hufferd > Sr. Executive Director of Technology > Brocade Communications Systems, Inc > jhufferd@brocade.com > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > > > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of > Ken Sandars > Sent: Wednesday, August 31, 2005 12:57 PM > To: 'Mallikarjun C.'; 'IPS' > Subject: RE: [Ips] Discovery reinstatement > > Hi Mallikarjun, > > I like your approach to this problem. In my mind the answer to question > 1 is > a strong yes, however, I do not like the clause about Network Entity. > >>From my last posting, I restate: an initiator may not know if two > Portals > belong to the same Network Entity. For the purposes of discovery, all it > requires prior to establishing the discovery session is each Portal's > TCP > addressing information. > > Without a priori knowledge of which portals are in the same Network > Entity, > it would be difficult for an initiator to deterministically know if > starting > a discovery session to Portal Y is going to reinstate its existing > discovery > session on Portal X. > > Of the four possibilities you propose, I agree that II is on the path to > predictable behaviour. However, I suggest the decision to reinstate a > Discovery session should be based upon matching the tuple InitiatorName > + > ISID + servicing iSCSI Portal. Hence a Network Entity with four Portals > may > carry four discovery sessions simultaneously from the one > InitiatorName+ISID > pair (one per Portal). > > > Thanks, > Ken > > Ken Sandars > Adaptec UK > > >>-----Original Message----- >>From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On >>Behalf Of Mallikarjun C. >>Sent: 24 August 2005 21:04 >>To: IPS >>Subject: [Ips] Discovery reinstatement >> >> >>I spent sometime studying previous email threads on this >>topic and gave >>the topic some thought. My current thinking and rationale is written >>below, I hope we'll arrive at a consensus on this topic this >>time...... >> >>In short, I'm leaning towards not saying anything on discovery >>reinstatement in the Implementer's guide, but still open to being >>persuaded otherwise. Sorry it's a long note. >> >>[Options: >> >>A. TPGTs are always Node-scoped. If Node name isn't specified in the >>discovery Login Request PDU, TPGT is meaningless and can't be >>inferred >>(or inferred to be invalid). >> >>B. TPGTs are always Node-scoped. If Node name isn't specified in the >>discovery Login Request PDU, a special "No-Name" iSCSI Node >>is implied. >> This No-Name iSCSI Node has its own TPGT numbering space - >>one tag for >>each physically possible portal group - and thus the TPGT can >>be inferred. ] >> >> >>Question 1: >>Is it desirable that an initiator precisely know in advance when a new >>discovery session might reinstate an existing discovery session (with >>the same Network Entity)? >> >>Yes (based on the plugfest feedback), so let's analyze what >>this leads >>us to. If I got this wrong, feel free to reset me (especially to Bob >>Russell). >> >>If the answer is no, then the whole discussion is moot (jump >>down to the >>conclusions). >> >>Question 2: >>If so, how would the initiator deterministically know what reinstates >>what? >> >>Option A: >>Assuming a fixed InitiatorName and ISID pair, a new no-named discovery >>session will reinstate an old no-named discovery session if the >>following is met: >>(1) servicing iSCSI Portal (for the new session) is hosted by the >> same Network Entity as that of the existing session. >> >>Option B: >>Assuming a fixed InitiatorName and ISID pair, a new no-named discovery >>session will reinstate an old no-named discovery session if the >>following are met: >>(1) servicing iSCSI Portal (for the new session) is hosted by the >> same Network Entity as that of the existing session, and, >> >>(2) TPGT of the servicing iSCSI Portal (for the new session) matches >> that of the existing session. >> >>Question 3: >>Can the conditions for each option be met? >> >>Condition (1) can be met if we assume that the initiator has a >>(non-iSCSI) way of discovering that two IP addresses are hosted >>by one remote system (i.e. iSCSI Network Entity). >> >>Condition (2) for realizing Option B however cannot be met >>because TPGT >>is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the >>absence of a node name nor a way to communicate them to the initiator >>apriori. Besides, there's a bootstrapping problem in that a discovery >>session is needed to find out TPGT associations. >> >>So I believe condition (2) cannot be met, and thus do not see a way to >>support Option.B *given* the desire that the initiator >>deterministically >>predict session reinstatement in advance (answer to Question.1). >> >> >>To summarize: >> >>I see four possibilities (in decreasing order of my preference): >> >>I. We reject the assertion that initiator should be able to >> deterministically predict session reinstatement. So say >> nothing about this topic in the Implementer's guide. >> >>II. We accept the assertion. So mandate Option A in Implementer's >> guide. >> >>III.We "semi-accept" the assertion by saying that the initiator cannot >> predict reinstatement in advance but will know why a >>reinstatement >> happened post-fact (because the new session returned the >>same TPGT >> as did an existing no-named session). So mandate Option B in >> Implementer's guide. >> >>IV. We reject the assertion. Specify both Option A and >>Option B in the >> Implementer's guide. And leave it to implementer's discretion. >> >>I am personally fine with either I or II but not motivated to >>go to III >>because it does not satisfy the "predict in advance" desire even >>while it requires enhancements/changes to RFC 3720 (and by >>extension, to >>some existing implementations): >>a) allow a No-Name target node (i.e. a node that maps 1-to-1 >> with Network Entity) >>b) explicitly allow a TPGT numbering space for a No-Name target >>c) mandate returning TPGT on no-named discovery sessions. >>d) deal with second-order questions such as: shouldn't the >> No-Name target information be returned in SendTargets response? >> how about target port names for No-Name target node? .... >> >>The net is that I see very little ROI in III. >> >>I again see little ROI in IV. >>-- >>Mallikarjun >> >>Mallikarjun Chadalapaka >>Networked Storage Architecture >>StorageWorks Division >>Hewlett-Packard MS 5668 >>Roseville CA 95747 >>cbm [at] rose.hp.com >> >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips >> >> > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 01 22:57:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB1jj-0000TW-E0; Thu, 01 Sep 2005 22:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB1jg-0000TR-WF for ips@megatron.ietf.org; Thu, 01 Sep 2005 22:57:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25618 for ; Thu, 1 Sep 2005 22:56:58 -0400 (EDT) Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB1li-0006c3-CS for ips@ietf.org; Thu, 01 Sep 2005 22:59:09 -0400 Received: from [192.168.7.139] (helo=winminx) by hammer with esmtp (Exim 4.12) id 1EB1gh-0001F1-00; Fri, 02 Sep 2005 03:53:55 +0100 From: "Ken Sandars" To: "'William Studenmund'" Subject: RE: [Ips] Discovery reinstatement Date: Fri, 2 Sep 2005 03:56:45 +0100 Message-ID: <004001c5af69$f5004670$680115ac@elipsan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: 'IPS' , "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org On Sep 01, 2005, at 17:57 PM, William Studenmund wrote: > On Aug 31, 2005, at 12:56 PM, Ken Sandars wrote: >=20 > > Hi Mallikarjun, > > > > I like your approach to this problem. In my mind the answer to=20 > > question 1 is > > a strong yes, however, I do not like the clause about=20 > Network Entity. > > > >> From my last posting, I restate: an initiator may not know if two=20 > >> Portals > > belong to the same Network Entity. For the purposes of=20 > discovery, all=20 > > it > > requires prior to establishing the discovery session is=20 > each Portal's=20 > > TCP > > addressing information. > > > > Without a priori knowledge of which portals are in the same Network=20 > > Entity, > > it would be difficult for an initiator to deterministically know if=20 > > starting > > a discovery session to Portal Y is going to reinstate its existing=20 > > discovery > > session on Portal X. > > > > Of the four possibilities you propose, I agree that II is=20 > on the path=20 > > to > > predictable behaviour. However, I suggest the decision to=20 > reinstate a > > Discovery session should be based upon matching the tuple=20 > > InitiatorName + > > ISID + servicing iSCSI Portal. Hence a Network Entity with four=20 > > Portals may > > carry four discovery sessions simultaneously from the one=20 > > InitiatorName+ISID > > pair (one per Portal). >=20 > Your proposal basically is Option B, or Option III. :-) >=20 Nope. I made no reference to TPGT, only to Portal. As Mallikarjun said, = TPGT only makes sense in the scope of a node. In no way do I want to = introduce TPGT processing, the processing of more keys or other work added. In effect, the discovery session is to the Network Entity via any of its Network Portals (identified by its IP address and TCP port). From the initiator's perspective, it only knows about the Portal. Hence if the = target is thinking about reinstating any sessions, it should limit its scope of destruction to the same Portal. And I certainly don't want Option III - there is no "semi-acceptance" of = the assertion in what I'm suggesting. > Take care, >=20 > Bill >=20 Cheers, Ken _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 01 23:11:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB1xh-0004zw-PN; Thu, 01 Sep 2005 23:11:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB1xd-0004wg-95 for ips@megatron.ietf.org; Thu, 01 Sep 2005 23:11:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26140 for ; Thu, 1 Sep 2005 23:11:22 -0400 (EDT) Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB1zh-00070m-7H for ips@ietf.org; Thu, 01 Sep 2005 23:13:34 -0400 Received: from [192.168.7.139] (helo=winminx) by hammer with esmtp (Exim 4.12) id 1EB1ud-0001IM-00; Fri, 02 Sep 2005 04:08:19 +0100 From: "Ken Sandars" To: "'John Hufferd'" , "'Mallikarjun C.'" , "'IPS'" Subject: RE: [Ips] Discovery reinstatement Date: Fri, 2 Sep 2005 04:11:08 +0100 Message-ID: <004101c5af6b$f9af8bc0$680115ac@elipsan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi John, The target cares. Actually, we all care! ;-) I know the sane initiators out there use discovery sessions in the spirit intended. Get in, get the info, get out - no hanging around. But it's also OK for an initiator to keep a discovery session lying around. In this case there are no iSCSI mechanisms for the target Network Entity to check if the network connection is still viable. Unless it has lower layers checking connection state (e.g. TCP keep-alives), stale discovery sessions can accumulate over time. Yuck. At least reinstatement gives a positive indication to the target about the initiator's view. Personally, I HATE sustained discovery sessions! :-) As you said, the initiator should use iSNS instead. Cheers Ken Ken Sandars Adaptec UK > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of John Hufferd > Sent: 01 September 2005 18:09 > To: Mallikarjun C.; IPS > Subject: RE: [Ips] Discovery reinstatement > > > I guess I do not understand why anyone cares about the > reinstatement of > a discovery session. It was suppose to be simple and > straight forward. > I don't thing any of us thought that the discovery session was so > important that it needed reinstatement. It does a very simple thing, > has no direct relationship to any application, and has no > direct impact > on the operation of a SCSI I/O command. Further, it is easy enough to > just restart without having any state from a previous > connection. I see > no reason to make this complicated and then have the > implementers bother > with add'l lines of code, and tests, including the > interoperation test. > > The reinstatement was intended for normal connections that could be > carrying SCSI I/O operations, and we wanted to avoid the SCSI level > error recovery. > > I suggest that we keep this discovery stuff real simple and just have > the initiator restart the Discovery session (from Scratch) if > a problem > occurs. I also think that if for some reason an installation needs a > more robust discovery process, that they use something like iSNS. > > . > . > . > John L Hufferd > Sr. Executive Director of Technology > Brocade Communications Systems, Inc > jhufferd@brocade.com > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > > > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of > Ken Sandars > Sent: Wednesday, August 31, 2005 12:57 PM > To: 'Mallikarjun C.'; 'IPS' > Subject: RE: [Ips] Discovery reinstatement > > Hi Mallikarjun, > > I like your approach to this problem. In my mind the answer > to question > 1 is > a strong yes, however, I do not like the clause about Network Entity. > > >From my last posting, I restate: an initiator may not know if two > Portals > belong to the same Network Entity. For the purposes of > discovery, all it > requires prior to establishing the discovery session is each Portal's > TCP > addressing information. > > Without a priori knowledge of which portals are in the same Network > Entity, > it would be difficult for an initiator to deterministically know if > starting > a discovery session to Portal Y is going to reinstate its existing > discovery > session on Portal X. > > Of the four possibilities you propose, I agree that II is on > the path to > predictable behaviour. However, I suggest the decision to reinstate a > Discovery session should be based upon matching the tuple > InitiatorName > + > ISID + servicing iSCSI Portal. Hence a Network Entity with > four Portals > may > carry four discovery sessions simultaneously from the one > InitiatorName+ISID > pair (one per Portal). > > > Thanks, > Ken > > Ken Sandars > Adaptec UK > > > -----Original Message----- > > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > > Behalf Of Mallikarjun C. > > Sent: 24 August 2005 21:04 > > To: IPS > > Subject: [Ips] Discovery reinstatement > > > > > > I spent sometime studying previous email threads on this > > topic and gave > > the topic some thought. My current thinking and rationale > is written > > below, I hope we'll arrive at a consensus on this topic this > > time...... > > > > In short, I'm leaning towards not saying anything on discovery > > reinstatement in the Implementer's guide, but still open to being > > persuaded otherwise. Sorry it's a long note. > > > > [Options: > > > > A. TPGTs are always Node-scoped. If Node name isn't > specified in the > > discovery Login Request PDU, TPGT is meaningless and can't be > > inferred > > (or inferred to be invalid). > > > > B. TPGTs are always Node-scoped. If Node name isn't > specified in the > > discovery Login Request PDU, a special "No-Name" iSCSI Node > > is implied. > > This No-Name iSCSI Node has its own TPGT numbering space - > > one tag for > > each physically possible portal group - and thus the TPGT can > > be inferred. ] > > > > > > Question 1: > > Is it desirable that an initiator precisely know in advance > when a new > > discovery session might reinstate an existing discovery > session (with > > the same Network Entity)? > > > > Yes (based on the plugfest feedback), so let's analyze what > > this leads > > us to. If I got this wrong, feel free to reset me > (especially to Bob > > Russell). > > > > If the answer is no, then the whole discussion is moot (jump > > down to the > > conclusions). > > > > Question 2: > > If so, how would the initiator deterministically know what > reinstates > > what? > > > > Option A: > > Assuming a fixed InitiatorName and ISID pair, a new > no-named discovery > > session will reinstate an old no-named discovery session if the > > following is met: > > (1) servicing iSCSI Portal (for the new session) is hosted by the > > same Network Entity as that of the existing session. > > > > Option B: > > Assuming a fixed InitiatorName and ISID pair, a new > no-named discovery > > session will reinstate an old no-named discovery session if the > > following are met: > > (1) servicing iSCSI Portal (for the new session) is hosted by the > > same Network Entity as that of the existing session, and, > > > > (2) TPGT of the servicing iSCSI Portal (for the new session) matches > > that of the existing session. > > > > Question 3: > > Can the conditions for each option be met? > > > > Condition (1) can be met if we assume that the initiator has a > > (non-iSCSI) way of discovering that two IP addresses are hosted > > by one remote system (i.e. iSCSI Network Entity). > > > > Condition (2) for realizing Option B however cannot be met > > because TPGT > > is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the > > absence of a node name nor a way to communicate them to the > initiator > > apriori. Besides, there's a bootstrapping problem in that > a discovery > > session is needed to find out TPGT associations. > > > > So I believe condition (2) cannot be met, and thus do not > see a way to > > support Option.B *given* the desire that the initiator > > deterministically > > predict session reinstatement in advance (answer to Question.1). > > > > > > To summarize: > > > > I see four possibilities (in decreasing order of my preference): > > > > I. We reject the assertion that initiator should be able to > > deterministically predict session reinstatement. So say > > nothing about this topic in the Implementer's guide. > > > > II. We accept the assertion. So mandate Option A in Implementer's > > guide. > > > > III.We "semi-accept" the assertion by saying that the > initiator cannot > > predict reinstatement in advance but will know why a > > reinstatement > > happened post-fact (because the new session returned the > > same TPGT > > as did an existing no-named session). So mandate Option B in > > Implementer's guide. > > > > IV. We reject the assertion. Specify both Option A and > > Option B in the > > Implementer's guide. And leave it to implementer's discretion. > > > > I am personally fine with either I or II but not motivated to > > go to III > > because it does not satisfy the "predict in advance" desire even > > while it requires enhancements/changes to RFC 3720 (and by > > extension, to > > some existing implementations): > > a) allow a No-Name target node (i.e. a node that maps 1-to-1 > > with Network Entity) > > b) explicitly allow a TPGT numbering space for a No-Name target > > c) mandate returning TPGT on no-named discovery sessions. > > d) deal with second-order questions such as: shouldn't the > > No-Name target information be returned in SendTargets response? > > how about target port names for No-Name target node? .... > > > > The net is that I see very little ROI in III. > > > > I again see little ROI in IV. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > StorageWorks Division > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm [at] rose.hp.com > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 09:18:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBBQl-0005WO-MJ; Fri, 02 Sep 2005 09:18:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBBQg-0005OO-B1 for ips@megatron.ietf.org; Fri, 02 Sep 2005 09:18:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05169 for ; Fri, 2 Sep 2005 09:18:01 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBBSp-0002T3-32 for ips@ietf.org; Fri, 02 Sep 2005 09:20:16 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j82DHmpS024723 for ; Fri, 2 Sep 2005 09:17:49 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Sep 2005 09:17:48 -0400 Message-ID: To: ips@ietf.org Date: Fri, 2 Sep 2005 09:17:34 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.2.10 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Black_David@emc.com Subject: [Ips] APB - Missing RFC Authors X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I have the proverbial "good news" and "bad news" ... Good news: The iFCP, iSNS, and iSCSI Boot drafts are in Authors' 48 hour review - the final stage before RFC publication. Bad news: We're missing some RFC authors, who MUST be found in order for these RFCs to be published. The RFC Editor requires review and approval from *every* RFC author before publication. This is (in part) because an RFC cannot be changed after it is published. So, if anyone knows where to find: iFCP - Mark Edwards (formerly with Eurologic) iSNS - Joe Souza (formerly with Microsoft) iSCSI Boot - Duncan Missimer (formerly with Brocade) Please tell them to contact me ASAP! Today would be much better than sometime next week, when I'll be in Europe. Many Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 10:16:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCLX-0007qx-KM; Fri, 02 Sep 2005 10:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCLU-0007qe-Vu for ips@megatron.ietf.org; Fri, 02 Sep 2005 10:16:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09031 for ; Fri, 2 Sep 2005 10:16:43 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBCNe-0004ax-8M for ips@ietf.org; Fri, 02 Sep 2005 10:18:59 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j82EGYil025645 for ; Fri, 2 Sep 2005 10:16:34 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j82EGYje025638; Fri, 2 Sep 2005 10:16:34 -0400 Received: from pkoning.equallogic.com ([172.16.1.163]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 10:16:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17176.24256.812256.855713@gargle.gargle.HOWL> Date: Fri, 2 Sep 2005 10:16:32 -0400 From: Paul Koning To: ken_sandars@adaptec.com Subject: RE: [Ips] Discovery reinstatement References: <004101c5af6b$f9af8bc0$680115ac@elipsan.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 02 Sep 2005 14:16:34.0089 (UTC) FILETIME=[EC312190:01C5AFC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Ken" == Ken Sandars writes: Ken> Hi John, The target cares. Actually, we all care! ;-) Ken> I know the sane initiators out there use discovery sessions in Ken> the spirit intended. Get in, get the info, get out - no hanging Ken> around. Ken> But it's also OK for an initiator to keep a discovery session Ken> lying around. In this case there are no iSCSI mechanisms for Ken> the target Network Entity to check if the network connection is Ken> still viable. Unless it has lower layers checking connection Ken> state (e.g. TCP keep-alives), stale discovery sessions can Ken> accumulate over time. Yuck. At least reinstatement gives a Ken> positive indication to the target about the initiator's view. I'm not sure what reinstatement does to help here. Yes, stale discovery sessions can accumulate. Since there is no good reason for discovery sessions to be long-lived, the target clearly should feel free to do garbage collection whenever that seems useful. This can be done based on lower level triggers (TCP keepalive), idleness, elapsed time, whatever. Getting another discovery session from the same initiator could be viewed as another hint. Then again, it may be that a target implementation doesn't know or care whether there are multiple discovery sessions with a given initiator (I don't see a good reason why it should bother checking, if that doesn't come naturally from the logic it was using anyway). So I'd look at it this way: 1. Discovery sessions should not be long lived. 2. Initiators should not open more than one discovery session to a given target. 3. Targets may handle duplicate discovery sessions from a given target as they wish, i.e., they are free to check for it or not, they are free to close one of them or not. 4. ErrorRecoveryLevel should be 0 for discovery sessions. So in response to Mallikarjun's question of "should a discovery session wipe out an old session with the same coordinates at the network entity level... or the physical portal group level ..." -- I guess I don't really understand what difference it makes. If the rule for the initiator is "don't do that" then the target can pick any of those rules, or none of them (i.e., leave the old connection around, garbage collected at the target's leasure if it wants to) -- whichever is most convenient for the implementation. After all, what bad results could there possibly be to an initiator that's doing the right thing? paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 11:35:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDa6-0004QG-9E; Fri, 02 Sep 2005 11:35:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDa4-0004Q8-Ov for ips@megatron.ietf.org; Fri, 02 Sep 2005 11:35:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14066 for ; Fri, 2 Sep 2005 11:35:50 -0400 (EDT) Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDcG-0007eL-4r for ips@ietf.org; Fri, 02 Sep 2005 11:38:08 -0400 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Fri, 02 Sep 2005 09:35:43 -0600 Message-Id: <43181CE4.E5CE.0060.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Fri, 02 Sep 2005 09:35:33 -0600 From: "Chaofeng Kao" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Ips] What is the max size of value for CHAP_C for iSCSI X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I want to know do we have the maximum size of value for CHAP challenge (CHAP_C) for iSCSI login process? Thanks, Chaofeng Kao Platform Services 1-5458 ckao@novell.com Novell, Inc., the leading provider of Net Services Software _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 11:51:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDoo-0003mL-TP; Fri, 02 Sep 2005 11:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDon-0003mA-RS for ips@megatron.ietf.org; Fri, 02 Sep 2005 11:51:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14834 for ; Fri, 2 Sep 2005 11:51:03 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDqz-0008Cj-6T for ips@ietf.org; Fri, 02 Sep 2005 11:53:21 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 4A0CF87061; Fri, 2 Sep 2005 11:50:52 -0400 (EDT) In-Reply-To: <004001c5af69$f5004670$680115ac@elipsan.com> References: <004001c5af69$f5004670$680115ac@elipsan.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <970e7fdcb8f713957ce694c5de110d36@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery reinstatement Date: Fri, 2 Sep 2005 08:50:43 -0700 To: "Ken Sandars" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: 'IPS' , "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1103924279==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1103924279== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--807328017" Content-Transfer-Encoding: 7bit --Apple-Mail-1--807328017 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 1, 2005, at 7:56 PM, Ken Sandars wrote: > Nope. I made no reference to TPGT, only to Portal. As Mallikarjun > said, TPGT > only makes sense in the scope of a node. In no way do I want to > introduce > TPGT processing, the processing of more keys or other work added. True, I missed that detail. :-) The main reason I'd still mention the phrase TPGT is that it's what's in the ISID rule and all sessions obey the ISID rule. :-) > In effect, the discovery session is to the Network Entity via any of > its > Network Portals (identified by its IP address and TCP port). From the > initiator's perspective, it only knows about the Portal. Hence if the > target > is thinking about reinstating any sessions, it should limit its scope > of > destruction to the same Portal. I like this. I had thought of it yesterday, then realized that's what you're talking about. I think this will avoid the main concern I had with the "NUL TPGT" which is that having a new discovery session to the no-target target name would REQUIRE other discovery sessions to be closed. Allowing TPGT was a way to create domains beyond which we didn't care about other sessions. Your suggestion is to make each portal such a domain. So I officially change my mind. I like this idea. As for the ISID rule and the no-name target, we can say that a target should act AS IF each TCP port (and other ports for other protocols) had different TPGT values for the ISID rule. The exact (pseudo)values do not matter and need not be transmitted to the initiator; they exist only to cause the ISID rule to not apply between ports. The only time that an initiator will run into an issue with parallel discovery is if it tries to connect to the same IP/port twice in the same run. But it should be smart enough to notice that first... Take care, Bill --Apple-Mail-1--807328017 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDGHTZDJT2Egh26K0RAktmAJ91qRxGtiPriRu090xHKF0tDf/PQgCgjT5f XuBpJ1lV+NHMkyoToOEWVnc= =hj+m -----END PGP SIGNATURE----- --Apple-Mail-1--807328017-- --===============1103924279== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1103924279==-- From ips-bounces@ietf.org Fri Sep 02 11:56:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDtr-0005qK-6j; Fri, 02 Sep 2005 11:56:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBDto-0005pw-QX for ips@megatron.ietf.org; Fri, 02 Sep 2005 11:56:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15110 for ; Fri, 2 Sep 2005 11:56:14 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBDvx-0008M3-7G for ips@ietf.org; Fri, 02 Sep 2005 11:58:32 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j82Fu4ij001033 for ; Fri, 2 Sep 2005 11:56:04 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j82Fu4je001028; Fri, 2 Sep 2005 11:56:04 -0400 Received: from PKONING.equallogic.com ([172.16.1.186]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 11:56:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17176.30227.721000.996628@gargle.gargle.HOWL> Date: Fri, 2 Sep 2005 11:56:03 -0400 From: Paul Koning To: CKAO@novell.com Subject: Re: [Ips] What is the max size of value for CHAP_C for iSCSI References: <43181CE4.E5CE.0060.0@novell.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 02 Sep 2005 15:56:04.0614 (UTC) FILETIME=[D2E6F260:01C5AFD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Chaofeng" == Chaofeng Kao writes: Chaofeng> I want to know do we have the maximum size of value for Chaofeng> CHAP challenge (CHAP_C) for iSCSI login process? Section 11.1.4 says 1024 bytes. If it's a strong random number (as it should be) that's much more than is useful -- 16 bytes would be the minimum adequate length, a bit more (up to 32 or so) would ok too. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 12:46:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBEgP-0004QT-Iq; Fri, 02 Sep 2005 12:46:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBEgO-0004QE-0t for ips@megatron.ietf.org; Fri, 02 Sep 2005 12:46:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17082 for ; Fri, 2 Sep 2005 12:46:25 -0400 (EDT) From: Sears_Bill@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBEiW-0001bO-Ud for ips@ietf.org; Fri, 02 Sep 2005 12:48:44 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j82GkHrW025348; Fri, 2 Sep 2005 12:46:22 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Sep 2005 12:46:17 -0400 Message-ID: <05AADEB492F5824996D28D504686739906210D@CORPUSMX40A.corp.emc.com> To: CKAO@novell.com, ips@ietf.org Subject: RE: [Ips] What is the max size of value for CHAP_C for iSCSI Date: Fri, 2 Sep 2005 12:46:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.2.16 X-PerlMx-Spam: Gauge=, SPAM=7%, Reasons='EMC_FROM_00+ 0, NO_REAL_NAME 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The spec is pretty clear in 11.1.4: C and R are large-binary-values and their binary length (not the length of the character string that represents them in encoded form) MUST not exceed 1024 bytes. -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Chaofeng Kao Sent: Friday, September 02, 2005 11:36 AM To: ips@ietf.org Subject: [Ips] What is the max size of value for CHAP_C for iSCSI I want to know do we have the maximum size of value for CHAP challenge (CHAP_C) for iSCSI login process? Thanks, Chaofeng Kao Platform Services 1-5458 ckao@novell.com Novell, Inc., the leading provider of Net Services Software _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 12:48:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBEi7-0004yg-KR; Fri, 02 Sep 2005 12:48:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBEi5-0004yP-Gk for ips@megatron.ietf.org; Fri, 02 Sep 2005 12:48:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17144 for ; Fri, 2 Sep 2005 12:48:11 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBEkG-0001fg-EC for ips@ietf.org; Fri, 02 Sep 2005 12:50:29 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j82Gm6A2023440 for ; Fri, 2 Sep 2005 12:48:08 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Sep 2005 12:48:05 -0400 Message-ID: To: ips@ietf.org Subject: RE: [Ips] What is the max size of value for CHAP_C for iSCSI Date: Fri, 2 Sep 2005 12:47:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.2.16 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I want to reinforce one of Paul's points: > Section 11.1.4 says 1024 bytes. If it's a strong random number (as it > should be) that's much more than is useful -- 16 bytes would be the > minimum adequate length, a bit more (up to 32 or so) would ok too. The security of iSCSI CHAP is based on use of strong random numbers for challenges, and especially for CHAP secrets. If easy-to-remember things (e.g., passwords) are used for secrets, the resulting security is weak and easy to break. To a first approximation, anything that is easy for a human to remember is weak and vulnerable to a brute force guessing attack, and for CHAP, that attack is off-line (can be done in private as it's not necessary to check each possibility against the system to be attacked). The bottom line is: **Don't use weak secrets such as passwords with iSCSI CHAP, and don't encourage or enable their use**. Also, most pseudo random number generators do not generate strong random numbers. Don't use pseudo random number generators to generate iSCSI CHAP challenges or secrets unless you know *exactly* what you're doing (requires cryptographic expertise) and have a cryptographically strong pseudo random number generator (e.g., uses SHA-1 as part of the generation algorithm). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 13:13:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBF6H-00089T-Iv; Fri, 02 Sep 2005 13:13:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBF6F-00089O-KE for ips@megatron.ietf.org; Fri, 02 Sep 2005 13:13:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18387 for ; Fri, 2 Sep 2005 13:13:08 -0400 (EDT) Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBF8O-0002Ze-Ae for ips@ietf.org; Fri, 02 Sep 2005 13:15:27 -0400 Received: from [192.168.7.172] (helo=winminx) by hammer with esmtp (Exim 4.12) id 1EBF3A-0004Vs-00; Fri, 02 Sep 2005 18:10:00 +0100 From: "Ken Sandars" To: "'Paul Koning'" Subject: RE: [Ips] Discovery reinstatement Date: Fri, 2 Sep 2005 18:12:27 +0100 Message-ID: <002801c5afe1$936b43b0$ac07a8c0@elipsan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <17176.24256.812256.855713@gargle.gargle.HOWL> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Paul, When I've got my 'target' hat on, I do tend to agree with your cavalier attitude! If a rule is there and the other party breaks it, then by all means give them a good slapping. ;-) However, looking at it from the initiator's perspective, how does it know prior to opening a discovery session on a Portal (i.e. just an IP address + TCP port combination) what Network Entity (read: target) it belongs to? Please consider the plight of the initiator which has been told of four Portals to attempt discovery on. Has it broken any rule when these are on separate Network Entities? I say no. What has changed when these Portals turn out to be on the same Network Entity? All good implementers expect the unexpected, but it seems harsh to make the unexpected reinstatement of a live discovery session a normal working condition for the initiator. Especially when its only 'crime' has been to attempt parallel discovery. I think my real issue here is about when a target MUST NOT reinstate a discovery session, as opposed to when it SHOULD or MAY. Cheers, Ken > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Paul Koning > Sent: 02 September 2005 15:17 > To: ken_sandars@adaptec.com > Cc: ips@ietf.org > Subject: RE: [Ips] Discovery reinstatement > > > >>>>> "Ken" == Ken Sandars writes: > > Ken> Hi John, The target cares. Actually, we all care! ;-) > > Ken> I know the sane initiators out there use discovery sessions in > Ken> the spirit intended. Get in, get the info, get out - no hanging > Ken> around. > > Ken> But it's also OK for an initiator to keep a discovery session > Ken> lying around. In this case there are no iSCSI mechanisms for > Ken> the target Network Entity to check if the network connection is > Ken> still viable. Unless it has lower layers checking connection > Ken> state (e.g. TCP keep-alives), stale discovery sessions can > Ken> accumulate over time. Yuck. At least reinstatement gives a > Ken> positive indication to the target about the initiator's view. > > I'm not sure what reinstatement does to help here. > > Yes, stale discovery sessions can accumulate. Since there is no good > reason for discovery sessions to be long-lived, the target clearly > should feel free to do garbage collection whenever that seems useful. > This can be done based on lower level triggers (TCP keepalive), > idleness, elapsed time, whatever. > > Getting another discovery session from the same initiator could be > viewed as another hint. Then again, it may be that a target > implementation doesn't know or care whether there are multiple > discovery sessions with a given initiator (I don't see a good reason > why it should bother checking, if that doesn't come naturally from the > logic it was using anyway). > > So I'd look at it this way: > > 1. Discovery sessions should not be long lived. > 2. Initiators should not open more than one discovery session to a > given target. > 3. Targets may handle duplicate discovery sessions from a given target > as they wish, i.e., they are free to check for it or not, they are > free to close one of them or not. > 4. ErrorRecoveryLevel should be 0 for discovery sessions. > > So in response to Mallikarjun's question of "should a discovery > session wipe out an old session with the same coordinates at the > network entity level... or the physical portal group level ..." -- I > guess I don't really understand what difference it makes. If the rule > for the initiator is "don't do that" then the target can pick any of > those rules, or none of them (i.e., leave the old connection around, > garbage collected at the target's leasure if it wants to) -- whichever > is most convenient for the implementation. After all, what bad > results could there possibly be to an initiator that's doing the right > thing? > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 13:32:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBFPC-00086U-13; Fri, 02 Sep 2005 13:32:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBFPA-00086P-3x for ips@megatron.ietf.org; Fri, 02 Sep 2005 13:32:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19403 for ; Fri, 2 Sep 2005 13:32:41 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBFRM-0003Ht-AJ for ips@ietf.org; Fri, 02 Sep 2005 13:35:00 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j82HWWil008065 for ; Fri, 2 Sep 2005 13:32:32 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j82HWWje008060; Fri, 2 Sep 2005 13:32:32 -0400 Received: from pkoning.equallogic.com ([172.16.1.163]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 13:32:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17176.36015.332935.532609@gargle.gargle.HOWL> Date: Fri, 2 Sep 2005 13:32:31 -0400 From: Paul Koning To: Black_David@emc.com Subject: RE: [Ips] What is the max size of value for CHAP_C for iSCSI References: X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 02 Sep 2005 17:32:32.0420 (UTC) FILETIME=[4CB40E40:01C5AFE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Black" == Black David writes: Black> Also, most pseudo random number generators do not generate Black> strong random numbers. Don't use pseudo random number Black> generators to generate iSCSI CHAP challenges or secrets unless Black> you know *exactly* what you're doing (requires cryptographic Black> expertise) and have a cryptographically strong pseudo random Black> number generator (e.g., uses SHA-1 as part of the generation Black> algorithm). That's excellent advice. I'd add a few points to this: 1. Read RFC 1750. Until you understand what it is telling, you don't know enough to proceed. 2. See if your OS has a "cryptographically strong random number generator" -- such as /dev/random in Linux and NetBSD. If yes, AND it is hooked up to sources of entropy, your best answer almost certainly is to use it (but see point 1). The reason for the point about entropy: if you're building an embedded system, the conventional sources of entropy that the /dev/random code uses may not be active at all, and you'll have to search for others. (If you do, again see point 1.) paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 13:44:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBFaA-00045N-Bb; Fri, 02 Sep 2005 13:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBFa9-00045I-Dz for ips@megatron.ietf.org; Fri, 02 Sep 2005 13:44:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19940 for ; Fri, 2 Sep 2005 13:44:04 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBFcK-0003f7-Fh for ips@ietf.org; Fri, 02 Sep 2005 13:46:21 -0400 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j82Hfhu29511; Fri, 2 Sep 2005 13:41:43 -0400 (EDT) Received: from TRAVOS-2K.nortel.com (travos-2k.us.nortel.com [47.16.54.211]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFPRK4Q; Fri, 2 Sep 2005 13:43:42 -0400 Message-Id: <6.2.3.4.2.20050902133753.03b4e2b8@zbl6c002.corpeast.baynetworks.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 02 Sep 2005 13:43:41 -0400 To: Black_David@emc.com, ips@ietf.org From: "Franco Travostino" Subject: Re: [Ips] APB - Missing RFC Authors In-Reply-To: References: Mime-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: kevin Gibbons , Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0612129345==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0612129345== Content-Type: multipart/alternative; boundary="=====================_13694411==.ALT" --=====================_13694411==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:17 AM 9/2/2005, Black_David@emc.com wrote: >So, if anyone knows where to find: > iFCP - Mark Edwards (formerly with Eurologic) > iSNS - Joe Souza (formerly with Microsoft) > iSCSI Boot - Duncan Missimer (formerly with Brocade) Mark Edwards and Joe Souza have ACKed back to us. We're still missing Curt DuLaney, iSNS co-author formerly with IBM. Does anyone know Curt's new coordinates? thanks -franco >Please tell them to contact me ASAP! Today would be >much better than sometime next week, when I'll be in >Europe. > >Many Thanks, >--David >---------------------------------------------------- >David L. Black, Senior Technologist >EMC Corporation, 176 South St., Hopkinton, MA 01748 >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >black_david@emc.com Mobile: +1 (978) 394-7754 >---------------------------------------------------- > >_______________________________________________ >Ips mailing list >Ips@ietf.org >https://www1.ietf.org/mailman/listinfo/ips > --=====================_13694411==.ALT Content-Type: text/html; charset="us-ascii" At 09:17 AM 9/2/2005, Black_David@emc.com wrote:
So, if anyone knows where to find:
        iFCP - Mark Edwards (formerly with Eurologic)
        iSNS - Joe Souza (formerly with Microsoft)
        iSCSI Boot - Duncan Missimer (formerly with Brocade)

Mark Edwards and Joe Souza have ACKed back to us. We're still missing Curt DuLaney, iSNS co-author formerly with IBM. Does anyone  know Curt's new coordinates?

thanks
-franco

Please tell them to contact me ASAP!  Today would be
much better than sometime next week, when I'll be in
Europe.

Many Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=====================_13694411==.ALT-- --===============0612129345== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0612129345==-- From ips-bounces@ietf.org Fri Sep 02 14:11:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBG0j-0008Ga-HT; Fri, 02 Sep 2005 14:11:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBG0h-0008Dq-7t for ips@megatron.ietf.org; Fri, 02 Sep 2005 14:11:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20948 for ; Fri, 2 Sep 2005 14:11:30 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBG2s-0004Uz-ET for ips@ietf.org; Fri, 02 Sep 2005 14:13:47 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j82IBKil010628 for ; Fri, 2 Sep 2005 14:11:20 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j82IBJje010623; Fri, 2 Sep 2005 14:11:19 -0400 Received: from pkoning.equallogic.com ([172.16.1.163]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Sep 2005 14:11:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17176.38342.729291.541149@gargle.gargle.HOWL> Date: Fri, 2 Sep 2005 14:11:18 -0400 From: Paul Koning To: ken_sandars@adaptec.com Subject: RE: [Ips] Discovery reinstatement References: <17176.24256.812256.855713@gargle.gargle.HOWL> <002801c5afe1$936b43b0$ac07a8c0@elipsan.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 02 Sep 2005 18:11:19.0765 (UTC) FILETIME=[B7E8B850:01C5AFE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Ken" == Ken Sandars writes: Ken> Hi Paul, When I've got my 'target' hat on, I do tend to agree Ken> with your cavalier attitude! If a rule is there and the other Ken> party breaks it, then by all means give them a good Ken> slapping. ;-) Ken> However, looking at it from the initiator's perspective, how Ken> does it know prior to opening a discovery session on a Portal Ken> (i.e. just an IP address + TCP port combination) what Network Ken> Entity (read: target) it belongs to? Ken> Please consider the plight of the initiator which has been told Ken> of four Portals to attempt discovery on. Has it broken any rule Ken> when these are on separate Network Entities? I say no. What has Ken> changed when these Portals turn out to be on the same Network Ken> Entity? Good point. Ken> All good implementers expect the unexpected, but it seems harsh Ken> to make the unexpected reinstatement of a live discovery session Ken> a normal working condition for the initiator. Especially when Ken> its only 'crime' has been to attempt parallel discovery. I agree. I would say that reinstatement doesn't apply to discovery sessions. Initiators shuldn't open multiple discovery sessions to teh same portal. Targets that advertise multiple addresses should be prepared for simultaneous discovery sessions to each of them from the same target, and should simply treat those as independent. That seems like the right answer given that, as you point out, the initiator can't prevent that (short of taking the inefficient approach of serializing everything). paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 16:48:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBISd-0005iT-QH; Fri, 02 Sep 2005 16:48:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBISb-0005ex-MM for ips@megatron.ietf.org; Fri, 02 Sep 2005 16:48:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01934 for ; Fri, 2 Sep 2005 16:48:27 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBIUo-0002E7-Gx for ips@ietf.org; Fri, 02 Sep 2005 16:50:47 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id C6EA6870B1; Fri, 2 Sep 2005 16:48:11 -0400 (EDT) In-Reply-To: <17176.38342.729291.541149@gargle.gargle.HOWL> References: <17176.24256.812256.855713@gargle.gargle.HOWL> <002801c5afe1$936b43b0$ac07a8c0@elipsan.com> <17176.38342.729291.541149@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <8169f0a45e8333d64d2ce68a46ad403a@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery reinstatement Date: Fri, 2 Sep 2005 13:48:04 -0700 To: Paul Koning X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ips@ietf.org, ken_sandars@adaptec.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0708438853==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0708438853== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--789487299" Content-Transfer-Encoding: 7bit --Apple-Mail-2--789487299 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 2, 2005, at 11:11 AM, Paul Koning wrote: > Ken> Please consider the plight of the initiator which has been told > Ken> of four Portals to attempt discovery on. Has it broken any rule > Ken> when these are on separate Network Entities? I say no. What has > Ken> changed when these Portals turn out to be on the same Network > Ken> Entity? > > Good point. > > Ken> All good implementers expect the unexpected, but it seems harsh > Ken> to make the unexpected reinstatement of a live discovery session > Ken> a normal working condition for the initiator. Especially when > Ken> its only 'crime' has been to attempt parallel discovery. Ken, I have to wonder why we really need parallel discovery. I'm not saying we should disallow it. But if you really have enough targets that you want to do discovery in parallel, I think you should be using something like iSNS or SLP for discovery. :-) > I agree. I would say that reinstatement doesn't apply to discovery > sessions. Well, I disagree. We have the ISID rule which says when reinstatement applies, and it does not include session type in its description. So it does apply. And in some cases, I think it really helps. And it would be a real pain to make exceptions to it for discovery sessions. Now, I don't mind if we play games with the rule for no-target-name sessions and let each portal be its own reinstatement domain (act as if each portal has its own TPGT value when performing ISID considerations). And I think we will end up with something that will make everyone happy. But the main thing is the ISID rule still applies, we just have the edge cases arranged such that folks will be unlikely to notice. > Initiators shuldn't open multiple discovery sessions to teh same > portal. Targets that advertise multiple addresses should be prepared > for simultaneous discovery sessions to each of them from the same > target, and should simply treat those as independent. That seems like > the right answer given that, as you point out, the initiator can't > prevent that (short of taking the inefficient approach of serializing > everything). If you mean "Targets that advertise multiple addresses should be prepared for simultaneous discovery sessions to each of them from the same _initiator_" then I agree (substituting in a SHOULD for should) assuming we are limiting this to no-target-name discovery. If you do discovery to a specific target, well, you need to respect its TPGT layout. :-) Take care, Bill --Apple-Mail-2--789487299 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDGLqJDJT2Egh26K0RAreZAJ9ZQIsyEEID4AlWquhgF4DYUTi8oACfbO35 6Ob020EPdEBMjHNOY4GdLpM= =WMRW -----END PGP SIGNATURE----- --Apple-Mail-2--789487299-- --===============0708438853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0708438853==-- From ips-bounces@ietf.org Fri Sep 02 17:58:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBJYR-000246-BH; Fri, 02 Sep 2005 17:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBJYP-00023c-Ku for ips@megatron.ietf.org; Fri, 02 Sep 2005 17:58:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04829 for ; Fri, 2 Sep 2005 17:58:31 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBJad-0004NF-7T for ips@ietf.org; Fri, 02 Sep 2005 18:00:52 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j82LwQ5X001807; Fri, 2 Sep 2005 17:58:29 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Sep 2005 17:58:26 -0400 Message-ID: To: ips@ietf.org Date: Fri, 2 Sep 2005 17:58:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.2.28 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: bwijnen@lucent.com, Black_David@emc.com, mankin@psg.com Subject: [Ips] IPS MIB status X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is the first of what will be a (hopefully short) series of messages about the status of the remaining MIBs in the IPS WG, in the hope that some light on the situation will help move things along. Let me know if I've gotten anything wrong ... We have 6 MIBs that have not yet been approved as RFCs: iFCP MIB, iSCSI MIB, SCSI MIB - Awaiting expert re-review by the OPS area. Bert Wijnen is the OPS AD responsible for making this happen. iSCSI Authorization MIB and FCIP MIB - Expert review comments were received requiring new versions of these MIBs. The responsible authors are Mark Bakke (iSCSI Authorization) and Anil Rijhsinghani (FCIP) iSNS MIB - Expert review comments have been received from the WG's MIB expert requiring a revised version before I can request publication. Kevin Gibbons is the responsible author. The next one of these status notes will be out in about 2 weeks - let's see how many of these people arrange not to be mentioned as "responsible" in that iteration ... Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 02 23:38:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOrR-0002tW-6X; Fri, 02 Sep 2005 23:38:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBOrP-0002tM-8U for ips@megatron.ietf.org; Fri, 02 Sep 2005 23:38:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27362 for ; Fri, 2 Sep 2005 23:38:28 -0400 (EDT) Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBOte-0008SQ-0k for ips@ietf.org; Fri, 02 Sep 2005 23:40:52 -0400 Received: from hq-ex-2.corp.brocade.com (hq-ex-2 [192.168.38.63]) by blasphemy.brocade.com (Postfix) with ESMTP id 5993C1429F; Fri, 2 Sep 2005 20:38:12 -0700 (PDT) Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by hq-ex-2.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Sep 2005 20:38:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Discovery reinstatement Date: Fri, 2 Sep 2005 20:38:11 -0700 Message-ID: Thread-Topic: [Ips] Discovery reinstatement Thread-Index: AcWwABNOjKnfoq52Tla+ysBoaxa6HAAMkcJQ From: "John Hufferd" To: "William Studenmund" , "Paul Koning" X-OriginalArrivalTime: 03 Sep 2005 03:38:12.0023 (UTC) FILETIME=[E8CB6C70:01C5B038] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: ips@ietf.org, ken_sandars@adaptec.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Again, I do not buy any of this. =20 If the initiator wants to do a bunch of stuff in parallel, that seems fine with me and it does not matter if the address are on the same Network Entities, especially since the initiator can not tell. But it is very possible that an Initiator could have address for Portals on lots of different Network Entities, and the address may be for portals that cover several nodes (or address for different portals for the same node) within the same Network Entity. So it might be possible that an initiator could want to do things in parallel. (Yes they should use iSNS, but ...) So if you just ignore all this "keep the discovery session like the regular session" stuff, there would be no problems, and it works for all initiators. (And since we need to deal with inactive discovery session anyway, nothing gets worse by ignoring all this stuff.) In all this communication, the only reason we are told that we need to handle discovery and normal sessions in a like manner is that -- for some implementation something is easer. Well maybe, but I do not buy it. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of William Studenmund Sent: Friday, September 02, 2005 1:48 PM To: Paul Koning Cc: ips@ietf.org; ken_sandars@adaptec.com Subject: Re: [Ips] Discovery reinstatement On Sep 2, 2005, at 11:11 AM, Paul Koning wrote: > Ken> Please consider the plight of the initiator which has been told > Ken> of four Portals to attempt discovery on. Has it broken any rule > Ken> when these are on separate Network Entities? I say no. What has > Ken> changed when these Portals turn out to be on the same Network > Ken> Entity? > > Good point. > > Ken> All good implementers expect the unexpected, but it seems harsh > Ken> to make the unexpected reinstatement of a live discovery session > Ken> a normal working condition for the initiator. Especially when > Ken> its only 'crime' has been to attempt parallel discovery. Ken, I have to wonder why we really need parallel discovery. I'm not=20 saying we should disallow it. But if you really have enough targets=20 that you want to do discovery in parallel, I think you should be using=20 something like iSNS or SLP for discovery. :-) > I agree. I would say that reinstatement doesn't apply to discovery > sessions. Well, I disagree. We have the ISID rule which says when reinstatement=20 applies, and it does not include session type in its description. So it=20 does apply. And in some cases, I think it really helps. And it would be=20 a real pain to make exceptions to it for discovery sessions. Now, I don't mind if we play games with the rule for no-target-name=20 sessions and let each portal be its own reinstatement domain (act as if=20 each portal has its own TPGT value when performing ISID=20 considerations). And I think we will end up with something that will=20 make everyone happy. But the main thing is the ISID rule still applies,=20 we just have the edge cases arranged such that folks will be unlikely=20 to notice. > Initiators shuldn't open multiple discovery sessions to teh same > portal. Targets that advertise multiple addresses should be prepared > for simultaneous discovery sessions to each of them from the same > target, and should simply treat those as independent. That seems like > the right answer given that, as you point out, the initiator can't > prevent that (short of taking the inefficient approach of serializing > everything). If you mean "Targets that advertise multiple addresses should be=20 prepared for simultaneous discovery sessions to each of them from the=20 same _initiator_" then I agree (substituting in a SHOULD for should)=20 assuming we are limiting this to no-target-name discovery. If you do=20 discovery to a specific target, well, you need to respect its TPGT=20 layout. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Sep 04 13:05:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBxvU-00031y-D2; Sun, 04 Sep 2005 13:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBxvS-00031G-ON; Sun, 04 Sep 2005 13:05:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14338; Sun, 4 Sep 2005 13:04:59 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBxy2-0002t6-Q8; Sun, 04 Sep 2005 13:07:44 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j84H4jO0146858; Sun, 4 Sep 2005 17:04:45 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j84H4jwk172928; Sun, 4 Sep 2005 19:04:45 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j84H4jQX021942; Sun, 4 Sep 2005 19:04:45 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j84H4jl1021939; Sun, 4 Sep 2005 19:04:45 +0200 In-Reply-To: <4317BC94.2040405@rose.hp.com> To: "Mallikarjun C." Subject: Re: [Ips] Discovery reinstatement MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_08012005NP August 01, 2005 From: Julian Satran Message-ID: Date: Sun, 4 Sep 2005 20:04:43 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 04/09/2005 20:04:44, Serialize complete at 04/09/2005 20:04:45, Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 04/09/2005 20:04:45 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ad60914b71abd47c285b3604f8c8304 Cc: IPS , ips-bounces@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0282101956==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0282101956== Content-Type: multipart/alternative; boundary="=_alternative 00586BEEC2257072_=" This is a multipart message in MIME format. --=_alternative 00586BEEC2257072_= Content-Type: text/plain; charset="US-ASCII" Mallikarjun, I think last note from Paul is a clean and good summary of all that has to be said (including the fact that discovery sessions are supposed to be short lived and target should feel free to garbage collect them). I would also add that the number of concurrent discovery sessions a target supports may be limited (to the number of ports? less?). Regards, Julo "Mallikarjun C." Sent by: ips-bounces@ietf.org 02-09-05 05:44 To IPS cc Subject Re: [Ips] Discovery reinstatement John says: > I suggest that we keep this discovery stuff real simple Paul says: >I agree. It seems that we're spending a lot of energy spelling >out a pile of special case rules Pat says: >John, I've been thinking the same thing. Did I finally see some new WG interest in this topic? :-) (Thanks John!) Actually, I very much agree with the sentiments. However, considering the list bandwidth spent over the last 2 years or so on this topic, seems to me that future bandwidth savings can be realized only by saying something definitive in the new guide. > The reinstatement was intended for normal connections that could be > carrying SCSI I/O operations, and we wanted to avoid the SCSI level > error recovery. Not really, session reinstatement is the antithesis of recovery. >just have > the initiator restart the Discovery session (from Scratch) if a problem > occurs. I also think that if for some reason an installation needs a > more robust discovery process, that they use something like iSNS Agreed. However, that though strictly isn't the question on hand - current question pertains to the target behavior. Should a discovery session wipe out an old session with the same coordinates at the network entity level (some/several of us, myself included, think so), or at the "physical" portal group level without a node context (at least one of us thinks so), or at the "physical" portal level without a node context (at least one of us thinks so)? I'm as eager as everyone to put this issue behind and move on, quick WG feedback certainly helps. Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com John Hufferd wrote: > I guess I do not understand why anyone cares about the reinstatement of > a discovery session. It was suppose to be simple and straight forward. > I don't thing any of us thought that the discovery session was so > important that it needed reinstatement. It does a very simple thing, > has no direct relationship to any application, and has no direct impact > on the operation of a SCSI I/O command. Further, it is easy enough to > just restart without having any state from a previous connection. I see > no reason to make this complicated and then have the implementers bother > with add'l lines of code, and tests, including the interoperation test. > > The reinstatement was intended for normal connections that could be > carrying SCSI I/O operations, and we wanted to avoid the SCSI level > error recovery. > > I suggest that we keep this discovery stuff real simple and just have > the initiator restart the Discovery session (from Scratch) if a problem > occurs. I also think that if for some reason an installation needs a > more robust discovery process, that they use something like iSNS. > > . > . > . > John L Hufferd > Sr. Executive Director of Technology > Brocade Communications Systems, Inc > jhufferd@brocade.com > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > > > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of > Ken Sandars > Sent: Wednesday, August 31, 2005 12:57 PM > To: 'Mallikarjun C.'; 'IPS' > Subject: RE: [Ips] Discovery reinstatement > > Hi Mallikarjun, > > I like your approach to this problem. In my mind the answer to question > 1 is > a strong yes, however, I do not like the clause about Network Entity. > >>From my last posting, I restate: an initiator may not know if two > Portals > belong to the same Network Entity. For the purposes of discovery, all it > requires prior to establishing the discovery session is each Portal's > TCP > addressing information. > > Without a priori knowledge of which portals are in the same Network > Entity, > it would be difficult for an initiator to deterministically know if > starting > a discovery session to Portal Y is going to reinstate its existing > discovery > session on Portal X. > > Of the four possibilities you propose, I agree that II is on the path to > predictable behaviour. However, I suggest the decision to reinstate a > Discovery session should be based upon matching the tuple InitiatorName > + > ISID + servicing iSCSI Portal. Hence a Network Entity with four Portals > may > carry four discovery sessions simultaneously from the one > InitiatorName+ISID > pair (one per Portal). > > > Thanks, > Ken > > Ken Sandars > Adaptec UK > > >>-----Original Message----- >>From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On >>Behalf Of Mallikarjun C. >>Sent: 24 August 2005 21:04 >>To: IPS >>Subject: [Ips] Discovery reinstatement >> >> >>I spent sometime studying previous email threads on this >>topic and gave >>the topic some thought. My current thinking and rationale is written >>below, I hope we'll arrive at a consensus on this topic this >>time...... >> >>In short, I'm leaning towards not saying anything on discovery >>reinstatement in the Implementer's guide, but still open to being >>persuaded otherwise. Sorry it's a long note. >> >>[Options: >> >>A. TPGTs are always Node-scoped. If Node name isn't specified in the >>discovery Login Request PDU, TPGT is meaningless and can't be >>inferred >>(or inferred to be invalid). >> >>B. TPGTs are always Node-scoped. If Node name isn't specified in the >>discovery Login Request PDU, a special "No-Name" iSCSI Node >>is implied. >> This No-Name iSCSI Node has its own TPGT numbering space - >>one tag for >>each physically possible portal group - and thus the TPGT can >>be inferred. ] >> >> >>Question 1: >>Is it desirable that an initiator precisely know in advance when a new >>discovery session might reinstate an existing discovery session (with >>the same Network Entity)? >> >>Yes (based on the plugfest feedback), so let's analyze what >>this leads >>us to. If I got this wrong, feel free to reset me (especially to Bob >>Russell). >> >>If the answer is no, then the whole discussion is moot (jump >>down to the >>conclusions). >> >>Question 2: >>If so, how would the initiator deterministically know what reinstates >>what? >> >>Option A: >>Assuming a fixed InitiatorName and ISID pair, a new no-named discovery >>session will reinstate an old no-named discovery session if the >>following is met: >>(1) servicing iSCSI Portal (for the new session) is hosted by the >> same Network Entity as that of the existing session. >> >>Option B: >>Assuming a fixed InitiatorName and ISID pair, a new no-named discovery >>session will reinstate an old no-named discovery session if the >>following are met: >>(1) servicing iSCSI Portal (for the new session) is hosted by the >> same Network Entity as that of the existing session, and, >> >>(2) TPGT of the servicing iSCSI Portal (for the new session) matches >> that of the existing session. >> >>Question 3: >>Can the conditions for each option be met? >> >>Condition (1) can be met if we assume that the initiator has a >>(non-iSCSI) way of discovering that two IP addresses are hosted >>by one remote system (i.e. iSCSI Network Entity). >> >>Condition (2) for realizing Option B however cannot be met >>because TPGT >>is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the >>absence of a node name nor a way to communicate them to the initiator >>apriori. Besides, there's a bootstrapping problem in that a discovery >>session is needed to find out TPGT associations. >> >>So I believe condition (2) cannot be met, and thus do not see a way to >>support Option.B *given* the desire that the initiator >>deterministically >>predict session reinstatement in advance (answer to Question.1). >> >> >>To summarize: >> >>I see four possibilities (in decreasing order of my preference): >> >>I. We reject the assertion that initiator should be able to >> deterministically predict session reinstatement. So say >> nothing about this topic in the Implementer's guide. >> >>II. We accept the assertion. So mandate Option A in Implementer's >> guide. >> >>III.We "semi-accept" the assertion by saying that the initiator cannot >> predict reinstatement in advance but will know why a >>reinstatement >> happened post-fact (because the new session returned the >>same TPGT >> as did an existing no-named session). So mandate Option B in >> Implementer's guide. >> >>IV. We reject the assertion. Specify both Option A and >>Option B in the >> Implementer's guide. And leave it to implementer's discretion. >> >>I am personally fine with either I or II but not motivated to >>go to III >>because it does not satisfy the "predict in advance" desire even >>while it requires enhancements/changes to RFC 3720 (and by >>extension, to >>some existing implementations): >>a) allow a No-Name target node (i.e. a node that maps 1-to-1 >> with Network Entity) >>b) explicitly allow a TPGT numbering space for a No-Name target >>c) mandate returning TPGT on no-named discovery sessions. >>d) deal with second-order questions such as: shouldn't the >> No-Name target information be returned in SendTargets response? >> how about target port names for No-Name target node? .... >> >>The net is that I see very little ROI in III. >> >>I again see little ROI in IV. >>-- >>Mallikarjun >> >>Mallikarjun Chadalapaka >>Networked Storage Architecture >>StorageWorks Division >>Hewlett-Packard MS 5668 >>Roseville CA 95747 >>cbm [at] rose.hp.com >> >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips >> >> > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00586BEEC2257072_= Content-Type: text/html; charset="US-ASCII"
Mallikarjun,

I think last note from Paul is a clean and good summary of all that has to be said (including the fact that discovery sessions are supposed to be short lived and target should feel free to garbage collect them). I would also add that the number of concurrent discovery sessions a target supports may be limited (to the number of ports? less?).

Regards,
Julo


"Mallikarjun C." <cbm@rose.hp.com>
Sent by: ips-bounces@ietf.org

02-09-05 05:44

To
IPS <ips@ietf.org>
cc
Subject
Re: [Ips] Discovery reinstatement





John says:
> I suggest that we keep this discovery stuff real simple

Paul says:
>I agree.  It seems that we're spending a lot of energy spelling
>out a pile of special case rules

Pat says:
>John, I've been thinking the same thing.

Did I finally see some new WG interest in this topic? :-)  (Thanks John!)

Actually, I very much agree with the sentiments.

However, considering the list bandwidth spent over the last 2 years or
so on this topic, seems to me that future bandwidth savings can be
realized only by saying something definitive in the new guide.

> The reinstatement was intended for normal connections that could be
> carrying SCSI I/O operations, and we wanted to avoid the SCSI level
> error recovery.

Not really, session reinstatement is the antithesis of recovery.

>just have
> the initiator restart the Discovery session (from Scratch) if a problem
> occurs.  I also think that if for some reason an installation needs a
> more robust discovery process, that they use something like iSNS

Agreed.  However, that though strictly isn't the question on hand -
current question pertains to the target behavior.  Should a discovery
session wipe out an old session with the same coordinates at the network
entity level (some/several of us, myself included, think so), or at the
"physical" portal group level without a node context (at least one of us
thinks so), or at the "physical" portal level without a node context (at
least one of us thinks so)?

I'm as eager as everyone to put this issue behind and move on, quick WG
feedback certainly helps.

Thanks.

Mallikarjun

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


John Hufferd wrote:
> I guess I do not understand why anyone cares about the reinstatement of
> a discovery session.  It was suppose to be simple and straight forward.
> I don't thing any of us thought that the discovery session was so
> important that it needed reinstatement.  It does a very simple thing,
> has no direct relationship to any application, and has no direct impact
> on the operation of a SCSI I/O command.  Further, it is easy enough to
> just restart without having any state from a previous connection.  I see
> no reason to make this complicated and then have the implementers bother
> with add'l lines of code, and tests, including the interoperation test.
>
> The reinstatement was intended for normal connections that could be
> carrying SCSI I/O operations, and we wanted to avoid the SCSI level
> error recovery.
>
> I suggest that we keep this discovery stuff real simple and just have
> the initiator restart the Discovery session (from Scratch) if a problem
> occurs.  I also think that if for some reason an installation needs a
> more robust discovery process, that they use something like iSNS.
>
> .
> .
> .
> John L Hufferd
> Sr. Executive Director of Technology
> Brocade Communications Systems, Inc
> jhufferd@brocade.com
> Office Phone: (408) 333-5244; eFAX: (408) 904-4688
> Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606
>
>
> -----Original Message-----
> From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of
> Ken Sandars
> Sent: Wednesday, August 31, 2005 12:57 PM
> To: 'Mallikarjun C.'; 'IPS'
> Subject: RE: [Ips] Discovery reinstatement
>
> Hi Mallikarjun,
>
> I like your approach to this problem. In my mind the answer to question
> 1 is
> a strong yes, however, I do not like the clause about Network Entity.
>
>>From my last posting, I restate: an initiator may not know if two
> Portals
> belong to the same Network Entity. For the purposes of discovery, all it
> requires prior to establishing the discovery session is each Portal's
> TCP
> addressing information.
>
> Without a priori knowledge of which portals are in the same Network
> Entity,
> it would be difficult for an initiator to deterministically know if
> starting
> a discovery session to Portal Y is going to reinstate its existing
> discovery
> session on Portal X.
>
> Of the four possibilities you propose, I agree that II is on the path to
> predictable behaviour. However, I suggest the decision to reinstate a
> Discovery session should be based upon matching the tuple InitiatorName
> +
> ISID + servicing iSCSI Portal. Hence a Network Entity with four Portals
> may
> carry four discovery sessions simultaneously from the one
> InitiatorName+ISID
> pair (one per Portal).
>
>
> Thanks,
> Ken
>
> Ken Sandars
> Adaptec UK
>
>
>>-----Original Message-----
>>From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On
>>Behalf Of Mallikarjun C.
>>Sent: 24 August 2005 21:04
>>To: IPS
>>Subject: [Ips] Discovery reinstatement
>>
>>
>>I spent sometime studying previous email threads on this
>>topic and gave
>>the topic some thought.  My current thinking and rationale is written
>>below, I hope we'll arrive at a consensus on this topic this
>>time......
>>
>>In short, I'm leaning towards not saying anything on discovery
>>reinstatement in the Implementer's guide, but still open to being
>>persuaded otherwise.  Sorry it's a long note.
>>
>>[Options:
>>
>>A. TPGTs are always Node-scoped.  If Node name isn't specified in the
>>discovery Login Request PDU, TPGT is meaningless and can't be
>>inferred
>>(or inferred to be invalid).
>>
>>B. TPGTs are always Node-scoped.  If Node name isn't specified in the
>>discovery Login Request PDU, a special "No-Name" iSCSI Node
>>is implied.
>>  This No-Name iSCSI Node has its own TPGT numbering space -
>>one tag for
>>each physically possible portal group - and thus the TPGT can
>>be inferred. ]
>>
>>
>>Question 1:
>>Is it desirable that an initiator precisely know in advance when a new
>>discovery session might reinstate an existing discovery session (with
>>the same Network Entity)?
>>
>>Yes (based on the plugfest feedback), so let's analyze what
>>this leads
>>us to.  If I got this wrong, feel free to reset me (especially to Bob
>>Russell).
>>
>>If the answer is no, then the whole discussion is moot (jump
>>down to the
>>conclusions).
>>
>>Question 2:
>>If so, how would the initiator deterministically know what reinstates
>>what?
>>
>>Option A:
>>Assuming a fixed InitiatorName and ISID pair, a new no-named discovery
>>session will reinstate an old no-named discovery session if the
>>following is met:
>>(1) servicing iSCSI Portal (for the new session) is hosted by the
>>     same Network Entity as that of the existing session.
>>
>>Option B:
>>Assuming a fixed InitiatorName and ISID pair, a new no-named discovery
>>session will reinstate an old no-named discovery session if the
>>following are met:
>>(1) servicing iSCSI Portal (for the new session) is hosted by the
>>     same Network Entity as that of the existing session, and,
>>
>>(2) TPGT of the servicing iSCSI Portal (for the new session) matches
>>     that of the existing session.
>>
>>Question 3:
>>Can the conditions for each option be met?
>>
>>Condition (1) can be met if we assume that the initiator has a
>>(non-iSCSI) way of discovering that two IP addresses are hosted
>>by one remote system (i.e. iSCSI Network Entity).
>>
>>Condition (2) for realizing Option B however cannot be met
>>because TPGT
>>is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the
>>absence of a node name nor a way to communicate them to the initiator
>>apriori.  Besides, there's a bootstrapping problem in that a discovery
>>session is needed to find out TPGT associations.
>>
>>So I believe condition (2) cannot be met, and thus do not see a way to
>>support Option.B *given* the desire that the initiator
>>deterministically
>>predict session reinstatement in advance (answer to Question.1).
>>
>>
>>To summarize:
>>
>>I see four possibilities (in decreasing order of my preference):
>>
>>I.  We reject the assertion that initiator should be able to
>>     deterministically predict session reinstatement.  So say
>>     nothing about this topic in the Implementer's guide.
>>
>>II. We accept the assertion.  So mandate Option A in Implementer's
>>     guide.
>>
>>III.We "semi-accept" the assertion by saying that the initiator cannot
>>     predict reinstatement in advance but will know why a
>>reinstatement
>>     happened post-fact (because the new session returned the
>>same TPGT
>>     as did an existing no-named session).  So mandate Option B in
>>     Implementer's guide.
>>
>>IV. We reject the assertion.  Specify both Option A and
>>Option B in the
>>     Implementer's guide.  And leave it to implementer's discretion.
>>
>>I am personally fine with either I or II but not motivated to
>>go to III
>>because it does not satisfy the "predict in advance" desire even
>>while it requires enhancements/changes to RFC 3720 (and by
>>extension, to
>>some existing implementations):
>>a) allow a No-Name target node (i.e. a node that maps 1-to-1
>>    with Network Entity)
>>b) explicitly allow a TPGT numbering space for a No-Name target
>>c) mandate returning TPGT on no-named discovery sessions.
>>d) deal with second-order questions such as: shouldn't the
>>    No-Name target information be returned in SendTargets response?
>>    how about target port names for No-Name target node? ....
>>
>>The net is that I see very little ROI in III.
>>
>>I again see little ROI in IV.
>>--
>>Mallikarjun
>>
>>Mallikarjun Chadalapaka
>>Networked Storage Architecture
>>StorageWorks Division
>>Hewlett-Packard MS 5668
>>Roseville CA 95747
>>cbm [at] rose.hp.com
>>
>>
>>_______________________________________________
>>Ips mailing list
>>Ips@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ips
>>
>>
>
>
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00586BEEC2257072_=-- --===============0282101956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0282101956==-- From ips-bounces@ietf.org Sun Sep 04 18:35:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC34p-0008Rg-Hz; Sun, 04 Sep 2005 18:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC34n-0008RN-Iy for ips@megatron.ietf.org; Sun, 04 Sep 2005 18:35:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29745 for ; Sun, 4 Sep 2005 18:34:58 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EC37P-0002KF-KK for ips@ietf.org; Sun, 04 Sep 2005 18:37:46 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j84MX1g4019001; Sun, 4 Sep 2005 17:33:02 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 5 Sep 2005 00:33:01 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507EE1058@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kevin Gibbons , kzm@cisco.com, "Ipswg (E-mail)" Date: Mon, 5 Sep 2005 00:32:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: "Charles Monia \(email\)" , "Mike MacFaden \(E-mail\)" , Jayesh Gada , mankin@psg.com, Annie Wang , Black_David@emc.com, Joe White , mrm@macfaden.com, travos@nortelnetworks.com, ElizabethRodriguez@ieee.org, Josh Tseng , Scott Kipp , Larry Hofer Subject: [Ips] MIB Doctor review: draft-ietf-ips-ifcp-mib-06.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Sorry that it took so long to get back to this Summary: - as far as I am concerned this is good enuf to do IETF Last Call. And then you can consider the below as the first IETF Last Call comments to be addressed. - Did the WG agree with all the changes made from rev 05 to rev 06? There were quite some changes that I think need to be verified to have consensus in the WG. More details: Looks much better than last time I reviewed. - In the cases where you use STorageType, the DESCRIPTION clause MUST specify for which columns read-write acces is needed in case of a permanent row (RFC2579 explains this in the DESCRIPTION clause of the STorageType TC. Keith knows all about this. - ZeroBasedCounterxx definitions do have text "since the iFCP connection was first established." Although at startup they start from zero, they can wrap around, and so you cannot assume that the value is always "since..." I would just remove the "since ..." clause of each of those sentences in your MIB module. - The have a discontinuity timer, in which you describe that it acts as the discontinuity timer for all ZeroBaseCounters However, formally you must specify in the DESCRIPTION clause of EACH such counter which object is the discontinuity timer. Keith knows all about this. Maybe it is too much of a CLR (Crappy Little Rule). So I won't block on it. But... By the way, a wraparound is NOT considered a discontinuity. Issues with references and citations (not really a MIB Doctor specific issue, but rather a generic issues): !! Missing citation for Normative reference: P001 L1331: 1 [ENTMBV3] Bierman, A., and McCloghrie, K., "Entity MIB (Version !! Missing citation for Informative reference: P001 L1377: 7 [FC-FS] Fibre Channel Framing and Signaling Interface, !! Missing citation for Informative reference: P001 L1380: 0 [FC-GS] Fibre Channel - Generic Services, NCITS 348-2000. !! Missing citation for Normative reference: P001 L1323: 3 [IFCP001] Charles Monia, Rod Mullendore, Franco Travostino, !! Missing citation for Normative reference: P001 L1338: 8 [RFC2021] S. Waldbusser, "Remote Network Monitoring Management !! Missing citation for Normative reference: P001 L1348: 8 [RFC2571] D. Harrington, R. Presuhn, and B. Wijnen, "An By the way, RFC2571 has been obsoleted (a long time ago already) by RFC3411. !! Missing citation for Normative reference: P001 L1341: 1 [RFC2856] A. Bierman, K. McCloghrie, "Textual Conventions for !! Missing citation for Normative reference: P001 L1334: 4 [RFC3291] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder by the wau, RFC3291 has been obsoleted byh RFC4001 A good way to include a citation is to add some prelimenary text just nbefore the MIB module aka: The following MIB module imports from XXX-MIB [RFCxxxx], YYY-MIB [RFCyyyy] and .... I guess you get the gist. Bert > -----Original Message----- > From: Kevin Gibbons [mailto:kevin.gibbons@mcdata.com] > Sent: Monday, January 31, 2005 20:55 > To: internet-drafts@ietf.org > Cc: bwijnen@lucent.com; kzm@cisco.com; mrm@macfaden.com; > Black_David@emc.com; ElizabethRodriguez@ieee.org; > mankin@psg.com; Scott > Kipp; Larry Hofer; G D Ramkumar; Charles Monia (email); Josh Tseng; > travos@nortelnetworks.com; Jayesh Gada; Annie Wang; Joe White > Subject: Updated iFCP MIB draft > > > > The attached document (draft-ietf-ips-ifcp-mib-06.txt) is an official > IETF standards track document. Please post this draft and announce it > on the IPS Working Group reflector: ips@ietf.org. > > Thanks very much, > Kevin > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 06 12:30:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECgKx-0005Yd-MV; Tue, 06 Sep 2005 12:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECgKv-0005YY-GZ for ips@megatron.ietf.org; Tue, 06 Sep 2005 12:30:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06656 for ; Tue, 6 Sep 2005 12:30:15 -0400 (EDT) Received: from roadrunner-base.egenera.com ([63.160.166.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECgNu-0001ck-Nz for ips@ietf.org; Tue, 06 Sep 2005 12:33:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by roadrunner.egenera.com (Postfix) with ESMTP id D5A11A0507 for ; Tue, 6 Sep 2005 12:30:00 -0400 (EDT) Received: from roadrunner-base.egenera.com ([127.0.0.1]) by localhost (coyote.egenera.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13340-08 for ; Tue, 6 Sep 2005 12:29:59 -0400 (EDT) Received: from [172.23.2.91] (southeast.egenera.com [63.160.166.4]) by roadrunner.egenera.com (Postfix) with ESMTP id 2F867A0504 for ; Tue, 6 Sep 2005 12:29:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IPS From: Steve Byan Date: Tue, 6 Sep 2005 12:30:06 -0400 X-Mailer: Apple Mail (2.622) X-Virus-Scanned: amavisd-new at egenera.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Subject: [Ips] iSNS State Change Notification (SCN) X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I'm trying to discern the intention of the iSNS draft with respect to when iSCSI targets should send state change notifications and with respect to the meaning of the bits in the iSCSI Node SCN Bitmap. I'm not a Fibre Channel expert, but it's my understanding that it's customary for Fibre Channel storage arrays to send a registered state change notification when the logical unit inventory changes. If an iSCSI target changes its logical unit inventory, is it the intention of the iSNS draft that the target could send an SCN message? What bit should the target set in the SCN bitmap - the "TARGET AND SELF INFORMATION ONLY" bit? I find the description of the TARGET AND SELF INFORMATION ONLY and INITIATOR AND SELF INFORMATION ONLY bits somewhat hard to follow. Draft 22 says: > TARGET AND SELF INFORMATION ONLY SCNs (bit 25) provides information > only about changes to target devices, or if the iSCSI Storage Node > itself has undergone a change. Similarly, INITIATOR AND SELF > INFORMATION ONLY SCNs (bit 24) provides information only about > changes to initiator Nodes, or the target itself. Should "iSCSI Storage Node itself" in the first sentence be read as "initiator Node itself"? Just what circumstances should an iSNS server consider to have changed the "initiator Node itself"? Similarly, what circumstances should an iSNS server consider to have changed "the target itself"? In summary, 1) does iSNS provide a mechanism for targets to notify initiators of the need to perform logical unit discovery, and 2) if so, what is that mechanism? If iSNS SCNs are not intended for this use, then the initiator will have to rely on receiving a REPORTED LUNS DATA HAS CHANGED unit attention condition. Note that unit attention conditions are lossy and rely on the initiator polling the target in order to provide prompt notification of a condition. Regards, -Steve -------- Steve Byan Software Architect Egenera, Inc. 165 Forest Street Marlboro, MA 01752 (508) 858-3125 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 06 13:45:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChVJ-0008TP-1P; Tue, 06 Sep 2005 13:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChVH-0008Sn-8V for ips@megatron.ietf.org; Tue, 06 Sep 2005 13:45:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09681 for ; Tue, 6 Sep 2005 13:45:02 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EChYE-0003UW-69 for ips@ietf.org; Tue, 06 Sep 2005 13:48:10 -0400 Received: from phys-giza-1 ([129.147.4.102]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j86HitTY021725 for ; Tue, 6 Sep 2005 11:44:55 -0600 (MDT) Received: from conversion-daemon.giza-mail1.Central.Sun.COM by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IME00401OVYL3@giza-mail1.Central.Sun.COM> (original mail from David.Weibel@Sun.COM) for ips@ietf.org; Tue, 06 Sep 2005 11:44:55 -0600 (MDT) Received: from [172.20.58.39] (dwmorgan.Central.Sun.COM [172.20.58.39]) by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IME00841PA4U1@giza-mail1.Central.Sun.COM>; Tue, 06 Sep 2005 11:44:28 -0600 (MDT) Date: Tue, 06 Sep 2005 11:41:58 -0600 From: David Weibel Subject: Re: [Ips] iSNS State Change Notification (SCN) In-reply-to: To: Steve Byan Message-id: <431DD4E6.3010400@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7BIT Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David.Weibel@Sun.COM List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org It sounds like your focusing on a logical unit change for a discovered target. In this case it seems like a iSCSI ASYNC PDU with sense data would be the correct solution to notifying the initiator. Steve Byan wrote: > I'm trying to discern the intention of the iSNS draft with respect to > when iSCSI targets should send state change notifications and with > respect to the meaning of the bits in the iSCSI Node SCN Bitmap. > > I'm not a Fibre Channel expert, but it's my understanding that it's > customary for Fibre Channel storage arrays to send a registered state > change notification when the logical unit inventory changes. > > If an iSCSI target changes its logical unit inventory, is it the > intention of the iSNS draft that the target could send an SCN message? > What bit should the target set in the SCN bitmap - the "TARGET AND > SELF INFORMATION ONLY" bit? > > I find the description of the TARGET AND SELF INFORMATION ONLY and > INITIATOR AND SELF INFORMATION ONLY bits somewhat hard to follow. > Draft 22 says: > >> TARGET AND SELF INFORMATION ONLY SCNs (bit 25) provides information >> only about changes to target devices, or if the iSCSI Storage Node >> itself has undergone a change. Similarly, INITIATOR AND SELF >> INFORMATION ONLY SCNs (bit 24) provides information only about >> changes to initiator Nodes, or the target itself. > > Should "iSCSI Storage Node itself" in the first sentence be read as > "initiator Node itself"? Just what circumstances should an iSNS server > consider to have changed the "initiator Node itself"? Similarly, what > circumstances should an iSNS server consider to have changed "the > target itself"? > > In summary, > 1) does iSNS provide a mechanism for targets to notify initiators of > the need to perform logical unit discovery, and > 2) if so, what is that mechanism? > > If iSNS SCNs are not intended for this use, then the initiator will > have to rely on receiving a REPORTED LUNS DATA HAS CHANGED unit > attention condition. Note that unit attention conditions are lossy and > rely on the initiator polling the target in order to provide prompt > notification of a condition. > > Regards, > -Steve _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 06 14:28:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECiBI-0007SS-DS; Tue, 06 Sep 2005 14:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECiBE-0007SF-UD; Tue, 06 Sep 2005 14:28:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11700; Tue, 6 Sep 2005 14:28:23 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECiEF-0004hB-5R; Tue, 06 Sep 2005 14:31:32 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 928928708B; Tue, 6 Sep 2005 14:28:08 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <0af10644a65c2802fa0ec0f283d39b54@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery reinstatement Date: Tue, 6 Sep 2005 11:28:02 -0700 To: Julian Satran X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: IPS , ips-bounces@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0948704911==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0948704911== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--452288727" Content-Transfer-Encoding: 7bit --Apple-Mail-1--452288727 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 4, 2005, at 10:04 AM, Julian Satran wrote: > Mallikarjun, > > I think last note from Paul is a clean and good summary of all that > has to be said (including the fact that discovery sessions are > supposed to be short lived and target should feel free to garbage > collect them). I would also add that the number of concurrent > discovery sessions a target supports may be limited (to the number of > ports? less?). Julian and everyone on the list, I have the feeling that we all are talking past each other. What I'm not getting is that you say that a target should feel free to garbage collect discovery session and you agree with Paul's latest test. Well, Paul's latest text said that discovery sessions shouldn't reinstate each other. But at ERL 0, what is reinstatement if not garbage collecting? So how can garbage collecting be both appropriate when it's called garbage collection and inappropriate when it's called reinstatement? My concern is that if we aren't really listening to each other, then we may go with text that has unintended consequences. Take care, Bill --Apple-Mail-1--452288727 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDHd+4DJT2Egh26K0RAg1lAJsHj/ocIuVUC3pwd3ifMuJEUqsxwACdFHPQ zqq+YgIvhJ8vMSrZcOFFzJw= =S3zi -----END PGP SIGNATURE----- --Apple-Mail-1--452288727-- --===============0948704911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0948704911==-- From ips-bounces@ietf.org Tue Sep 06 14:38:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECiL8-00012u-TF; Tue, 06 Sep 2005 14:38:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECiL7-00012h-2j for ips@megatron.ietf.org; Tue, 06 Sep 2005 14:38:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12420 for ; Tue, 6 Sep 2005 14:38:35 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECiO8-000516-Fv for ips@ietf.org; Tue, 06 Sep 2005 14:41:44 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j86IcHij002372 for ; Tue, 6 Sep 2005 14:38:18 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j86IcHje002367; Tue, 6 Sep 2005 14:38:17 -0400 Received: from pkoning.equallogic.com ([172.16.1.163]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 6 Sep 2005 14:38:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17181.57880.141570.924490@gargle.gargle.HOWL> Date: Tue, 6 Sep 2005 14:38:16 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Subject: Re: [Ips] Discovery reinstatement References: <0af10644a65c2802fa0ec0f283d39b54@wasabisystems.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 06 Sep 2005 18:38:17.0895 (UTC) FILETIME=[260AC370:01C5B312] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org, Julian_Satran@il.ibm.com, cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I tend to think of "reinstatement" as "picking up state that was left around and continuing from where you left off". Error level 0 "reinstatement" seems like rather odd terminology in that you don't actually reinstate anything (in the English language sense of the word). paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 06 15:58:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECjaG-0003q1-9U; Tue, 06 Sep 2005 15:58:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECjaE-0003nE-4Z for ips@megatron.ietf.org; Tue, 06 Sep 2005 15:58:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20369 for ; Tue, 6 Sep 2005 15:58:16 -0400 (EDT) Received: from web60719.mail.yahoo.com ([209.73.178.207]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECjdE-0008I1-3m for ips@ietf.org; Tue, 06 Sep 2005 16:01:26 -0400 Received: (qmail 33077 invoked by uid 60001); 6 Sep 2005 19:58:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4MeQnXYbifuFXN3C4hQBfFboTDfUBYQZh/R3njnNEWhnxCRZmQJcrwfBe+FtgZKz+fcbRrkKIqnyZzDzzluL+GALUBy3kqIlUoHzxGilinIyTx0vXyHvmXEQR0UiuetjBA1K6eny22+ko76+V1rMsgBvZQuzCflQ6YOAI3yDb10= ; Message-ID: <20050906195807.33075.qmail@web60719.mail.yahoo.com> Received: from [12.18.128.130] by web60719.mail.yahoo.com via HTTP; Tue, 06 Sep 2005 12:58:06 PDT Date: Tue, 6 Sep 2005 12:58:06 -0700 (PDT) From: Joe Souza Subject: Re: [Ips] iSNS State Change Notification (SCN) To: Steve Byan , IPS In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 8bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org First, the target should not send SCN but rather the iSNS server. Of course it is possible that the iSNS server may be contained in the same physical device as an iSCSI target. Second, if you really want your target to be able to send SCN, there is an iSNS function for that (SCNEvent), but beware that some iSNS servers (i.e. Microsoft's) may not support this function as it could potentially be used to bring down an IP storage network by causing the iSNS server to generate a flood of SCN requests, each in turn potentially causing the registered iSNS clients in the affected Discovery Domain(s) to subsequently issue queries to rediscover registered IP storage nodes. In more specific answer to your question, perhaps it might be easier to understand the meaning of the SCN registrations if in your mind you ignore the "AND SELF" portion. The "AND SELF" text is necessary because you will always receive SCN's about yourself if you are registered to receive SCN's. The "INITIATOR" or "TARGET" specification indicates whether you are concerned with receiving SCN's about initiators, targets, or both. This granularity was provided because most initiators will only be concerned about changes to target registrations, and most targets will only be concerned about initiator registrations. If an initiator registers to receive SCN's by specifying "INITIATOR AND SELF" and not "TARGET AND SELF", then that initiator will receive SCN's which concern only targets which are members of at least one active Discovery Domain in common with the initiator. In further answer to your question, the target need not be concerned about sending SCN's. The iSNS server will send these whenever there is a registration/change/deregistration to a storage node in the database. In your case, for example, when you register your target with the iSNS server, the iSNS server will send SCN to any initiator which is a member of at least one active Discovery Domain in common with your target. Hope this makes sense and it answers your questions. -Joe Souza --- Steve Byan wrote: > I'm trying to discern the intention of the iSNS > draft with respect to > when iSCSI targets should send state change > notifications and with > respect to the meaning of the bits in the iSCSI Node > SCN Bitmap. > > I'm not a Fibre Channel expert, but it's my > understanding that it's > customary for Fibre Channel storage arrays to send a > registered state > change notification when the logical unit inventory > changes. > > If an iSCSI target changes its logical unit > inventory, is it the > intention of the iSNS draft that the target could > send an SCN message? > What bit should the target set in the SCN bitmap - > the "TARGET AND SELF > INFORMATION ONLY" bit? > > I find the description of the TARGET AND SELF > INFORMATION ONLY and > INITIATOR AND SELF INFORMATION ONLY bits somewhat > hard to follow. > Draft 22 says: > > > TARGET AND SELF INFORMATION ONLY SCNs (bit 25) > provides information > > only about changes to target devices, or if the > iSCSI Storage Node > > itself has undergone a change. Similarly, > INITIATOR AND SELF > > INFORMATION ONLY SCNs (bit 24) provides > information only about > > changes to initiator Nodes, or the target > itself. > > Should "iSCSI Storage Node itself" in the first > sentence be read as > "initiator Node itself"? Just what circumstances > should an iSNS server > consider to have changed the "initiator Node > itself"? Similarly, what > circumstances should an iSNS server consider to have > changed "the > target itself"? > > > > In summary, > 1) does iSNS provide a mechanism for targets to > notify initiators of > the need to perform logical unit discovery, and > 2) if so, what is that mechanism? > > If iSNS SCNs are not intended for this use, then the > initiator will > have to rely on receiving a REPORTED LUNS DATA HAS > CHANGED unit > attention condition. Note that unit attention > conditions are lossy and > rely on the initiator polling the target in order to > provide prompt > notification of a condition. > > Regards, > -Steve > -------- > Steve Byan > Software Architect > Egenera, Inc. > 165 Forest Street > Marlboro, MA 01752 > (508) 858-3125 > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 06 16:15:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECjn6-00070b-Sg; Tue, 06 Sep 2005 16:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECjn5-000709-4B for ips@megatron.ietf.org; Tue, 06 Sep 2005 16:11:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22140 for ; Tue, 6 Sep 2005 16:11:33 -0400 (EDT) Received: from web60723.mail.yahoo.com ([209.73.178.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECjq5-0000OG-3i for ips@ietf.org; Tue, 06 Sep 2005 16:14:43 -0400 Received: (qmail 67288 invoked by uid 60001); 6 Sep 2005 20:11:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CVULsRLJcmPeVQwUEuSMr0fYRrmZQhipQCzbH/OSNWc1PTUqqJ7qtJPuDdN0uwSx0qwh8gMEfUSlcCPefGI7f5LMsxd7czskTsDfUamZHhtZI9LrMKHX1TdTbAK5W3WlAqx+T9IdInKE/JsREZFcK5Zce1NFCPWvDcz+wRje7LU= ; Message-ID: <20050906201123.67286.qmail@web60723.mail.yahoo.com> Received: from [12.18.128.130] by web60723.mail.yahoo.com via HTTP; Tue, 06 Sep 2005 13:11:23 PDT Date: Tue, 6 Sep 2005 13:11:23 -0700 (PDT) From: Joe Souza Subject: Re: [Ips] iSNS State Change Notification (SCN) To: Steve Byan , IPS In-Reply-To: <20050906195807.33075.qmail@web60719.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 8bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I mistyped below, and I apologize for that. I meant to say: If an initiator registers to receive SCN's by specifying "TARGET AND SELF" and not "INITIATOR AND SELF", then that initiator will receive SCN's which concern only targets which are members of at least one active Discovery Domain in common with the initiator. Sorry for the confusion. -Joe --- Joe Souza wrote: > First, the target should not send SCN but rather the > iSNS server. Of course it is possible that the iSNS > server may be contained in the same physical device > as > an iSCSI target. Second, if you really want your > target to be able to send SCN, there is an iSNS > function for that (SCNEvent), but beware that some > iSNS servers (i.e. Microsoft's) may not support this > function as it could potentially be used to bring > down > an IP storage network by causing the iSNS server to > generate a flood of SCN requests, each in turn > potentially causing the registered iSNS clients in > the > affected Discovery Domain(s) to subsequently issue > queries to rediscover registered IP storage nodes. > > In more specific answer to your question, perhaps it > might be easier to understand the meaning of the SCN > registrations if in your mind you ignore the "AND > SELF" portion. The "AND SELF" text is necessary > because you will always receive SCN's about yourself > if you are registered to receive SCN's. The > "INITIATOR" or "TARGET" specification indicates > whether you are concerned with receiving SCN's about > initiators, targets, or both. This granularity was > provided because most initiators will only be > concerned about changes to target registrations, and > most targets will only be concerned about initiator > registrations. If an initiator registers to receive > SCN's by specifying "INITIATOR AND SELF" and not > "TARGET AND SELF", then that initiator will receive > SCN's which concern only targets which are members > of > at least one active Discovery Domain in common with > the initiator. > > In further answer to your question, the target need > not be concerned about sending SCN's. The iSNS > server will send these whenever there is a > registration/change/deregistration to a storage node > in the database. In your case, for example, when > you > register your target with the iSNS server, the iSNS > server will send SCN to any initiator which is a > member of at least one active Discovery Domain in > common with your target. > > Hope this makes sense and it answers your questions. > > -Joe Souza > > > > > --- Steve Byan wrote: > > > I'm trying to discern the intention of the iSNS > > draft with respect to > > when iSCSI targets should send state change > > notifications and with > > respect to the meaning of the bits in the iSCSI > Node > > SCN Bitmap. > > > > I'm not a Fibre Channel expert, but it's my > > understanding that it's > > customary for Fibre Channel storage arrays to send > a > > registered state > > change notification when the logical unit > inventory > > changes. > > > > If an iSCSI target changes its logical unit > > inventory, is it the > > intention of the iSNS draft that the target could > > send an SCN message? > > What bit should the target set in the SCN bitmap - > > the "TARGET AND SELF > > INFORMATION ONLY" bit? > > > > I find the description of the TARGET AND SELF > > INFORMATION ONLY and > > INITIATOR AND SELF INFORMATION ONLY bits somewhat > > hard to follow. > > Draft 22 says: > > > > > TARGET AND SELF INFORMATION ONLY SCNs (bit > 25) > > provides information > > > only about changes to target devices, or if > the > > iSCSI Storage Node > > > itself has undergone a change. Similarly, > > INITIATOR AND SELF > > > INFORMATION ONLY SCNs (bit 24) provides > > information only about > > > changes to initiator Nodes, or the target > > itself. > > > > Should "iSCSI Storage Node itself" in the first > > sentence be read as > > "initiator Node itself"? Just what circumstances > > should an iSNS server > > consider to have changed the "initiator Node > > itself"? Similarly, what > > circumstances should an iSNS server consider to > have > > changed "the > > target itself"? > > > > > > > > In summary, > > 1) does iSNS provide a mechanism for targets to > > notify initiators of > > the need to perform logical unit discovery, and > > 2) if so, what is that mechanism? > > > > If iSNS SCNs are not intended for this use, then > the > > initiator will > > have to rely on receiving a REPORTED LUNS DATA HAS > > CHANGED unit > > attention condition. Note that unit attention > > conditions are lossy and > > rely on the initiator polling the target in order > to > > provide prompt > > notification of a condition. > > > > Regards, > > -Steve > > -------- > > Steve Byan > > Software Architect > > Egenera, Inc. > > 165 Forest Street > > Marlboro, MA 01752 > > (508) 858-3125 > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 06 16:54:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECkST-000163-BB; Tue, 06 Sep 2005 16:54:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECkSP-00014X-CV for ips@megatron.ietf.org; Tue, 06 Sep 2005 16:54:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28213 for ; Tue, 6 Sep 2005 16:54:15 -0400 (EDT) Received: from roadrunner-base.egenera.com ([63.160.166.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECkVQ-0002TD-19 for ips@ietf.org; Tue, 06 Sep 2005 16:57:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by roadrunner.egenera.com (Postfix) with ESMTP id A68C2A0518; Tue, 6 Sep 2005 16:54:05 -0400 (EDT) Received: from roadrunner-base.egenera.com ([127.0.0.1]) by localhost (coyote.egenera.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20576-10; Tue, 6 Sep 2005 16:54:03 -0400 (EDT) Received: from [172.23.2.91] (southeast.egenera.com [63.160.166.4]) by roadrunner.egenera.com (Postfix) with ESMTP id E9532A0504; Tue, 6 Sep 2005 16:54:03 -0400 (EDT) In-Reply-To: <20050906195807.33075.qmail@web60719.mail.yahoo.com> References: <20050906195807.33075.qmail@web60719.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <41ca22af7325b4dac805a2779b2e6089@egenera.com> Content-Transfer-Encoding: 7bit From: Steve Byan Subject: Re: [Ips] iSNS State Change Notification (SCN) Date: Tue, 6 Sep 2005 16:54:11 -0400 To: IPS X-Mailer: Apple Mail (2.622) X-Virus-Scanned: amavisd-new at egenera.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: Joe Souza X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Joe, Thanks for the informative response. On Sep 6, 2005, at 3:58 PM, Joe Souza wrote: > First, the target should not send SCN but rather the > iSNS server. Of course it is possible that the iSNS > server may be contained in the same physical device as > an iSCSI target. Second, if you really want your > target to be able to send SCN, there is an iSNS > function for that (SCNEvent), I was speaking loosely. I meant that the target could send an SCN Event to the iSNS server, which would then cause the iSNS server to send an SCN to affected iSCSI nodes. If a target were to wish to send an SCN event message, just what should it put in its SCN bitmask? OBJECT UPDATED? > but beware that some > iSNS servers (i.e. Microsoft's) may not support this > function as it could potentially be used to bring down > an IP storage network by causing the iSNS server to > generate a flood of SCN requests, each in turn > potentially causing the registered iSNS clients in the > affected Discovery Domain(s) to subsequently issue > queries to rediscover registered IP storage nodes. Couldn't a malicious iSCSI node perform the same denial of service attack by continually de-registering and then re-registering? Isn't it up to the iSNS server to limit the frequency of SCN's pertaining to a single iSCSI node? > In more specific answer to your question, perhaps it > might be easier to understand the meaning of the SCN > registrations if in your mind you ignore the "AND > SELF" portion. The "AND SELF" text is necessary > because you will always receive SCN's about yourself > if you are registered to receive SCN's. The > "INITIATOR" or "TARGET" specification indicates > whether you are concerned with receiving SCN's about > initiators, targets, or both. This granularity was > provided because most initiators will only be > concerned about changes to target registrations, and > most targets will only be concerned about initiator > registrations. If an initiator registers to receive > SCN's by specifying "INITIATOR AND SELF" and not > "TARGET AND SELF", then that initiator will receive > SCN's which concern only targets which are members of > at least one active Discovery Domain in common with > the initiator. Thanks, I was under the mistaken impression that only the OBJECT REMOVED/ADDED/UPDATED bits were used for deletions, changes, or additions to discovery domains. Where's the text in the draft that specifies this behavior? I don't recall reading it. > In further answer to your question, the target need > not be concerned about sending SCN's. The iSNS > server will send these whenever there is a > registration/change/deregistration to a storage node > in the database. In your case, for example, when you > register your target with the iSNS server, the iSNS > server will send SCN to any initiator which is a > member of at least one active Discovery Domain in > common with your target. I'm asking how to communication the notification of changes in the logical unit inventory in a target that is already registered with the iSNS server. In this case, there is no registration or de-registration, unless the suggestion is that a target should de-register and then re-register when its logical unit inventory changes. Perhaps a better phrasing of my question is: How are iSCSI targets supposed to notify iSCSI initiators of a change in their logical unit inventory (i.e. a LUN has been added, removed, or the ACL for an initiator has changed)? In an off-list message, Dave Weibel pointed out to me the support for SCSI asynchronous event notification (AEN) in iSCSI. I had forgotten it was in the standard, since AEN is so rarely supported in the SCSI world and was obsoleted in SAM-3. Does Microsoft's initiator support AEN? Is that how Microsoft expects targets to inform the initiator of a change in logical unit inventory? Regards, -Steve -------- Steve Byan Software Architect Egenera, Inc. 165 Forest Street Marlboro, MA 01752 (508) 858-3125 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 06 20:07:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnTJ-0007C0-M1; Tue, 06 Sep 2005 20:07:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECnTH-0007Bv-Q8 for ips@megatron.ietf.org; Tue, 06 Sep 2005 20:07:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17057 for ; Tue, 6 Sep 2005 20:07:22 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECnWI-0002Bj-7k for ips@ietf.org; Tue, 06 Sep 2005 20:10:34 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 7A2D387095 for ; Tue, 6 Sep 2005 20:07:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <4209e5cc97cf74b05afedffc257cdff3@wasabisystems.com> To: IPS From: William Studenmund Date: Tue, 6 Sep 2005 17:06:53 -0700 X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Ips] Make ErrorRecoveryLevel Irrelevant for Discovery sessions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0700840125==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0700840125== Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--431958378" --Apple-Mail-2--431958378 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit As part of the great Discovery thread, I noticed that it is feasible to negotiate ERL > 0 for discovery sessions. However the PDUs necessary for ERL 1 and 2 functioning, SNACK and TASK MANAGEMENT, are not valid. So do we want to make the ErrorRecoveryLevel tag Irrelevant for SessionType=Discovery? Or do we just want to note that discovery sessions can not readily handle ERL > 0 and leave it to both sides to never negotiate higher? Take care, Bill --Apple-Mail-2--431958378 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDHi8oDJT2Egh26K0RAr9RAJ4zbHnduaf1x1I8ZycMFhPPbX1KoQCeIiu5 hDfuwRsMcJ0nGRZbRKxlPWw= =LK4t -----END PGP SIGNATURE----- --Apple-Mail-2--431958378-- --===============0700840125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0700840125==-- From ips-bounces@ietf.org Tue Sep 06 22:43:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECpud-0006s1-Bn; Tue, 06 Sep 2005 22:43:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECpuZ-0006lL-0W for ips@megatron.ietf.org; Tue, 06 Sep 2005 22:43:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22557 for ; Tue, 6 Sep 2005 22:43:40 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECpxd-0005SL-Cl for ips@ietf.org; Tue, 06 Sep 2005 22:46:54 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id C5D898706C; Tue, 6 Sep 2005 22:43:33 -0400 (EDT) In-Reply-To: <17181.57880.141570.924490@gargle.gargle.HOWL> References: <0af10644a65c2802fa0ec0f283d39b54@wasabisystems.com> <17181.57880.141570.924490@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <998f2baa0232ebb998da88b2acf9b830@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery reinstatement Date: Tue, 6 Sep 2005 19:43:27 -0700 To: Paul Koning X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ips@ietf.org, Julian_Satran@il.ibm.com, cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1485773016==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1485773016== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--422564133" Content-Transfer-Encoding: 7bit --Apple-Mail-4--422564133 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 6, 2005, at 11:38 AM, Paul Koning wrote: > I tend to think of "reinstatement" as "picking up state that was left > around and continuing from where you left off". Error level 0 > "reinstatement" seems like rather odd terminology in that you don't > actually reinstate anything (in the English language sense of the > word). I agree! But that is the term we use for session reinstatement in the RFC. That's why I think we've been talking past each other; when I've spoken of "reinstatement" it's always been the Error Level 0 odd-terminology kind. Garbage collecting. I guess the one thing you are doing is that you are reinstating the session to a clean, known state. Which is a good thing. Take care, Bill --Apple-Mail-4--422564133 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDHlPUDJT2Egh26K0RAr8ZAJ46ZdplABrl24vK0tVfh0+GfXa2NwCeP9BQ ho5vcuswdIMd1SwC+VJxSWE= =IFoM -----END PGP SIGNATURE----- --Apple-Mail-4--422564133-- --===============1485773016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1485773016==-- From ips-bounces@ietf.org Wed Sep 07 02:43:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECteZ-0000PC-AZ; Wed, 07 Sep 2005 02:43:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECteW-0000Or-Hm for ips@megatron.ietf.org; Wed, 07 Sep 2005 02:43:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00365 for ; Wed, 7 Sep 2005 02:43:23 -0400 (EDT) Received: from web60720.mail.yahoo.com ([209.73.178.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECthd-0002jz-KF for ips@ietf.org; Wed, 07 Sep 2005 02:46:38 -0400 Received: (qmail 67710 invoked by uid 60001); 7 Sep 2005 06:43:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Xwmbtkcthxvmvyy2tdrL+vgh16npDnIrguYLoC6zjVa0xSnhteMznoJIuLCNPpouosVWKY4L27vilH9DwYMmHLkMJCDTxVkiWcJrPOGuNIi/ik4iyrTm9TvhksvcSlNZl4vlKcD41Wa9fz+kS1+A1bQzuqmlGOowKmlL2/buw8s= ; Message-ID: <20050907064314.67708.qmail@web60720.mail.yahoo.com> Received: from [24.19.10.187] by web60720.mail.yahoo.com via HTTP; Tue, 06 Sep 2005 23:43:14 PDT Date: Tue, 6 Sep 2005 23:43:14 -0700 (PDT) From: Joe Souza Subject: Re: [Ips] iSNS State Change Notification (SCN) To: Steve Byan , IPS In-Reply-To: <41ca22af7325b4dac805a2779b2e6089@egenera.com> MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: iscsi@microsoft.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0068328270==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0068328270== Content-Type: multipart/alternative; boundary="0-927313147-1126075394=:67542" Content-Transfer-Encoding: 8bit --0-927313147-1126075394=:67542 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Steve, Responses inline below: Steve Byan wrote: Hi Joe, Thanks for the informative response. On Sep 6, 2005, at 3:58 PM, Joe Souza wrote: > First, the target should not send SCN but rather the > iSNS server. Of course it is possible that the iSNS > server may be contained in the same physical device as > an iSCSI target. Second, if you really want your > target to be able to send SCN, there is an iSNS > function for that (SCNEvent), I was speaking loosely. I meant that the target could send an SCN Event to the iSNS server, which would then cause the iSNS server to send an SCN to affected iSCSI nodes. If a target were to wish to send an SCN event message, just what should it put in its SCN bitmask? OBJECT UPDATED? [Joe Souza] Yes. > but beware that some > iSNS servers (i.e. Microsoft's) may not support this > function as it could potentially be used to bring down > an IP storage network by causing the iSNS server to > generate a flood of SCN requests, each in turn > potentially causing the registered iSNS clients in the > affected Discovery Domain(s) to subsequently issue > queries to rediscover registered IP storage nodes. Couldn't a malicious iSCSI node perform the same denial of service attack by continually de-registering and then re-registering? Isn't it up to the iSNS server to limit the frequency of SCN's pertaining to a single iSCSI node? [Joe Souza] You have a point, and an iSNS server implementation would need to guard against this type of attack as well. But there are also other reasons, in my opinion, why SCNEvent is not a good idea. One of the main goals for iSNS is for centralized management of an IP storage network. SCNEvent, in my opinion, is not conducive toward this end; it removes some of the management functionality and control away from the server and toward the clients. However, if you have strong feelings that the Microsoft iSNS server should support SCNEvent, you should send email to iscsi@microsoft.com expressing your concerns. I no longer work for Microsoft and thus am not the appropriate audience for such concerns. > In more specific answer to your question, perhaps it > might be easier to understand the meaning of the SCN > registrations if in your mind you ignore the "AND > SELF" portion. The "AND SELF" text is necessary > because you will always receive SCN's about yourself > if you are registered to receive SCN's. The > "INITIATOR" or "TARGET" specification indicates > whether you are concerned with receiving SCN's about > initiators, targets, or both. This granularity was > provided because most initiators will only be > concerned about changes to target registrations, and > most targets will only be concerned about initiator > registrations. If an initiator registers to receive > SCN's by specifying "INITIATOR AND SELF" and not > "TARGET AND SELF", then that initiator will receive > SCN's which concern only targets which are members of > at least one active Discovery Domain in common with > the initiator. Thanks, I was under the mistaken impression that only the OBJECT REMOVED/ADDED/UPDATED bits were used for deletions, changes, or additions to discovery domains. Where's the text in the draft that specifies this behavior? I don't recall reading it. [Joe Souza] Except for Management SCN's, which only Control Nodes receive, all SCN's are scoped to Discovery Domains where the recipient of the SCN shares at least one active Discovery Domain in common with the Node which caused the SCN to be generated. This is mentioned in section 5.6.5.8 State Change Notification (SCN) but is also more clearly described in section 5.6.5.5 SCN Register Request (SCNReg). SCN's are sent not only for changes to Discovery Domains but also for changes to Nodes which are members of active Discovery Domains. > In further answer to your question, the target need > not be concerned about sending SCN's. The iSNS > server will send these whenever there is a > registration/change/deregistration to a storage node > in the database. In your case, for example, when you > register your target with the iSNS server, the iSNS > server will send SCN to any initiator which is a > member of at least one active Discovery Domain in > common with your target. I'm asking how to communication the notification of changes in the logical unit inventory in a target that is already registered with the iSNS server. In this case, there is no registration or de-registration, unless the suggestion is that a target should de-register and then re-register when its logical unit inventory changes. Perhaps a better phrasing of my question is: How are iSCSI targets supposed to notify iSCSI initiators of a change in their logical unit inventory (i.e. a LUN has been added, removed, or the ACL for an initiator has changed)? In an off-list message, Dave Weibel pointed out to me the support for SCSI asynchronous event notification (AEN) in iSCSI. I had forgotten it was in the standard, since AEN is so rarely supported in the SCSI world and was obsoleted in SAM-3. Does Microsoft's initiator support AEN? Is that how Microsoft expects targets to inform the initiator of a change in logical unit inventory? [Joe Souza] I will defer to iscsi@microsoft.com for questions about the Microsoft initiator, but in answer to your question, using iSNS, the recommended method (in my opinion) for an iSCSI target to cause registered iSNS clients to receive SCN's for changes to iSCSI target nodes, would be for the target to send an UPDATE registration for the target node (i.e. send DevAttrReg message for the target node, with the Replace bit clear) that it wishes the SCN to be sent for. Regards, -Steve -------- Steve Byan Software Architect Egenera, Inc. 165 Forest Street Marlboro, MA 01752 (508) 858-3125 --0-927313147-1126075394=:67542 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Steve,
 
Responses inline below:

Steve Byan <smb@egenera.com> wrote:

Hi Joe,

Thanks for the informative response.

On Sep 6, 2005, at 3:58 PM, Joe Souza wrote:

> First, the target should not send SCN but rather the
> iSNS server. Of course it is possible that the iSNS
> server may be contained in the same physical device as
> an iSCSI target. Second, if you really want your
> target to be able to send SCN, there is an iSNS
> function for that (SCNEvent),

I was speaking loosely. I meant that the target could send an SCN Event
to the iSNS server, which would then cause the iSNS server to send an
SCN to affected iSCSI nodes.

If a target were to wish to send an SCN event message, just what should
it put in its SCN bitmask? OBJECT UPDATED?

[Joe Souza] Yes.

> but beware that some
> iSNS servers (i.e. Microsoft's) may not support this
> function as it could potentially be used to bring down
> an IP storage network by causing the iSNS server to
> generate a flood of SCN requests, each in turn
> potentially causing the registered iSNS clients in the
> affected Discovery Domain(s) to subsequently issue
> queries to rediscover registered IP storage nodes.

Couldn't a malicious iSCSI node perform the same denial of service
attack by continually de-registering and then re-registering? Isn't it
up to the iSNS server to limit the frequency of SCN's pertaining to a
single iSCSI node?

[Joe Souza] You have a point, and an iSNS server implementation would need to guard against this type of attack as well.  But there are also other reasons, in my opinion, why SCNEvent is not a good idea.  One of the main goals for iSNS is for centralized management of an IP storage network.  SCNEvent, in my opinion, is not conducive toward this end; it removes some of the management functionality and control away from the server and toward the clients.  However, if you have strong feelings that the Microsoft iSNS server should support SCNEvent, you should send email to iscsi@microsoft.com expressing your concerns.  I no longer work for Microsoft and thus am not the appropriate audience for such concerns.

> In more specific answer to your question, perhaps it
> might be easier to understand the meaning of the SCN
> registrations if in your mind you ignore the "AND
> SELF" portion.! The "AND SELF" text is necessary
> because you will always receive SCN's about yourself
> if you are registered to receive SCN's. The
> "INITIATOR" or "TARGET" specification indicates
> whether you are concerned with receiving SCN's about
> initiators, targets, or both. This granularity was
> provided because most initiators will only be
> concerned about changes to target registrations, and
> most targets will only be concerned about initiator
> registrations. If an initiator registers to receive
> SCN's by specifying "INITIATOR AND SELF" and not
> "TARGET AND SELF", then that initiator will receive
> SCN's which concern only targets which are members of
> at least one active Discovery Domain in common with
> the initiator.

Thanks, I was under the mistaken impression that only the OBJECT
REMOVED/ADDED/UPDATED bits were used for deletions, changes, or
additions to discovery domains. Wh! ere's the text in the draft that
specifies this behavior? I don't recall reading it.

[Joe Souza] Except for Management SCN's, which only Control Nodes receive, all SCN's are scoped to Discovery Domains where the recipient of the SCN shares at least one active Discovery Domain in common with the Node which caused the SCN to be generated.  This is mentioned in section 5.6.5.8 State Change Notification (SCN) but is also more clearly described in section 5.6.5.5 SCN Register Request (SCNReg).  SCN's are sent not only for changes to Discovery Domains but also for changes to Nodes which are members of active Discovery Domains.

> In further answer to your question, the target need
> not be concerned about sending SCN's. The iSNS
> server will send these whenever there is a
> registration/change/deregistration to a storage node
> in the database. In your case, for example, when you
> register your target with the iSNS server, the iSNS
> server will send SCN to any initiator which is a
> member of at le! ast one active Discovery Domain in
> common with your target.

I'm asking how to communication the notification of changes in the
logical unit inventory in a target that is already registered with the
iSNS server. In this case, there is no registration or de-registration,
unless the suggestion is that a target should de-register and then
re-register when its logical unit inventory changes.

Perhaps a better phrasing of my question is:

How are iSCSI targets supposed to notify iSCSI initiators of a change
in their logical unit inventory (i.e. a LUN has been added, removed, or
the ACL for an initiator has changed)?

In an off-list message, Dave Weibel pointed out to me the support for
SCSI asynchronous event notification (AEN) in iSCSI. I had forgotten it
was in the standard, since AEN is so rarely supported in the SCSI world
and was obsoleted in SAM-3. Does Microsoft's initiator support AEN? Is
that how Microsoft ! expects targets to inform the initiator of a change
in logical unit inventory?

[Joe Souza] I will defer to iscsi@microsoft.com for questions about the Microsoft initiator, but in answer to your question, using iSNS, the recommended method (in my opinion) for an iSCSI target to cause registered iSNS clients to receive SCN's for changes to iSCSI target nodes, would be for the target to send an UPDATE registration for the target node (i.e. send DevAttrReg message for the target node, with the Replace bit clear) that it wishes the SCN to be sent for.

Regards,
-Steve
--------
Steve Byan
Software Architect
Egenera, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 858-3125

--0-927313147-1126075394=:67542-- --===============0068328270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0068328270==-- From ips-bounces@ietf.org Wed Sep 07 08:51:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECzP0-0007tY-D9; Wed, 07 Sep 2005 08:51:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECzOx-0007sr-Pr for ips@megatron.ietf.org; Wed, 07 Sep 2005 08:51:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16815 for ; Wed, 7 Sep 2005 08:51:42 -0400 (EDT) Received: from roadrunner-base.egenera.com ([63.160.166.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECzS5-0004TI-BO for ips@ietf.org; Wed, 07 Sep 2005 08:55:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by roadrunner.egenera.com (Postfix) with ESMTP id A829AA0519; Wed, 7 Sep 2005 08:51:30 -0400 (EDT) Received: from roadrunner-base.egenera.com ([127.0.0.1]) by localhost (coyote.egenera.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31129-09; Wed, 7 Sep 2005 08:51:29 -0400 (EDT) Received: from [172.23.2.91] (southeast.egenera.com [63.160.166.4]) by roadrunner.egenera.com (Postfix) with ESMTP id EFD5CA050B; Wed, 7 Sep 2005 08:51:28 -0400 (EDT) In-Reply-To: <20050907064314.67708.qmail@web60720.mail.yahoo.com> References: <20050907064314.67708.qmail@web60720.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Byan Subject: Re: [Ips] iSNS State Change Notification (SCN) Date: Wed, 7 Sep 2005 08:51:27 -0400 To: Joe Souza X-Mailer: Apple Mail (2.622) X-Virus-Scanned: amavisd-new at egenera.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: IPS , iscsi@microsoft.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Joe, Thanks for your help. I've got a much clearer picture of how iSNS state change notifications are intended to be used now. Regards, -Steve -------- Steve Byan Software Architect Egenera, Inc. 165 Forest Street Marlboro, MA 01752 (508) 858-3125 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 07 12:16:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2b7-0005QG-BF; Wed, 07 Sep 2005 12:16:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2b4-0005Pf-Kl for ips@megatron.ietf.org; Wed, 07 Sep 2005 12:16:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29739 for ; Wed, 7 Sep 2005 12:16:23 -0400 (EDT) Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED2eD-0002Ei-OG for ips@ietf.org; Wed, 07 Sep 2005 12:19:45 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel9.hp.com (Postfix) with ESMTP id 91DA58832 for ; Wed, 7 Sep 2005 12:16:18 -0400 (EDT) Received: from [127.0.0.1] (palnai12-1519.corp.hp.com [15.244.197.239]) by rosemail.rose.hp.com (Postfix) with ESMTP id 97BF58319 for ; Wed, 7 Sep 2005 09:13:19 -0700 (PDT) Message-ID: <431F1250.2060504@rose.hp.com> Date: Wed, 07 Sep 2005 09:16:16 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] Data Out PDU's References: <7D036BD3216A084DB1BD9D62BCEAF29001119E68@mail1irv.inside.istor.com> <17172.41745.260474.196649@gargle.gargle.HOWL> <1125430022.10995.17.camel@duala1.corp.silverbacksystems.com> In-Reply-To: <1125430022.10995.17.camel@duala1.corp.silverbacksystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org While a literal reading of the text indeed implies what Gwendal says below, I do not believe that was really the intent of the RFC. The rest of the paragraph text only discusses R2T handling within a task, not across tasks. There are a couple of issues with the "must satisfy R2Ts in order across tasks" interpretation: Since other transports, FC and SAS included, do not require in-order data sequence transfers (on R2T-analogs) across tasks, building bridge devices becomes complex. With virtualizers, each task may in fact be serviced by a different "real" initiator, so enforcing order across them is complex. For these reasons, I intend to clarify in the implementer's guide that RFC3720's intended servicing order of R2Ts is only within a task but not across tasks. If you have concerns or questions on this proposed change, please speak up. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Gwendal Grignou wrote: > > On Tue, 2005-08-30 at 14:18 -0400, Paul Koning wrote: > >>>>>>>"Ken" == Ken Craig writes: >> >> Ken> I have a question about Data Out PDUs. I, as a Target, have >> Ken> negotiated DataSequenceInOrder and DataPDUInOrder. If I >> Ken> generate a R2T for two Write commands does the spec allow the >> Ken> Data Out PDUs for those two R2T's to be intermingled even though >> Ken> each Data Out PDU is in sequence and in order? >> >>Yes -- the ordering requirement is for order within a transfer, i.e., >>a single write command. > > I don't think so [10.8]: > > Within a CONNECTION outstanding R2Ts MUST be fulfilled by the initiator > in the order in which they were received. > > Gwendal. > > >> paul >> >> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 07 12:26:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2l8-0001FH-Aw; Wed, 07 Sep 2005 12:26:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2l7-0001FC-GN for ips@megatron.ietf.org; Wed, 07 Sep 2005 12:26:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00282 for ; Wed, 7 Sep 2005 12:26:47 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED2oJ-0002Zv-C3 for ips@ietf.org; Wed, 07 Sep 2005 12:30:08 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id 0CB8770B5 for ; Wed, 7 Sep 2005 09:26:03 -0700 (PDT) Received: from [127.0.0.1] (palnai12-1519.corp.hp.com [15.244.197.239]) by rosemail.rose.hp.com (Postfix) with ESMTP id 7221A8005 for ; Wed, 7 Sep 2005 09:23:04 -0700 (PDT) Message-ID: <431F149A.7060500@rose.hp.com> Date: Wed, 07 Sep 2005 09:26:02 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS Subject: Re: [Ips] Make ErrorRecoveryLevel Irrelevant for Discovery sessions References: <4209e5cc97cf74b05afedffc257cdff3@wasabisystems.com> In-Reply-To: <4209e5cc97cf74b05afedffc257cdff3@wasabisystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >So do > we want to make the ErrorRecoveryLevel tag Irrelevant for > SessionType=Discovery? Unless I see other objections, I intend to incorporate Bill's suggestion into the next draft, with one change. Rather than calling ErrorRecoveryLevel "irrelevant", I prefer to say that the negotiation of ErrorRecoveryLevel is irrelevant, and the operational ErrorRecoveryLevel must always be implicitly set to 0 for discovery sessions. On the main discovery thread, thanks for all the feedback. I intend to propose some specific text to the list in the next few days. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com William Studenmund wrote: > As part of the great Discovery thread, I noticed that it is feasible to > negotiate ERL > 0 for discovery sessions. However the PDUs necessary for > ERL 1 and 2 functioning, SNACK and TASK MANAGEMENT, are not valid. So do > we want to make the ErrorRecoveryLevel tag Irrelevant for > SessionType=Discovery? > > Or do we just want to note that discovery sessions can not readily > handle ERL > 0 and leave it to both sides to never negotiate higher? > > Take care, > > Bill > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 07 13:46:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED40a-0005Iz-3H; Wed, 07 Sep 2005 13:46:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED40Y-0005Ie-Ev for ips@megatron.ietf.org; Wed, 07 Sep 2005 13:46:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05483 for ; Wed, 7 Sep 2005 13:46:49 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED43l-0005EY-3q for ips@ietf.org; Wed, 07 Sep 2005 13:50:10 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 7DEED870F8; Wed, 7 Sep 2005 13:46:33 -0400 (EDT) In-Reply-To: <431F149A.7060500@rose.hp.com> References: <4209e5cc97cf74b05afedffc257cdff3@wasabisystems.com> <431F149A.7060500@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <23112c4cfc38eccfbc2086b715b6a617@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Make ErrorRecoveryLevel Irrelevant for Discovery sessions Date: Wed, 7 Sep 2005 10:46:25 -0700 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1669256386==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1669256386== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--368386101" Content-Transfer-Encoding: 7bit --Apple-Mail-1--368386101 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 7, 2005, at 9:26 AM, Mallikarjun C. wrote: > >So do > > we want to make the ErrorRecoveryLevel tag Irrelevant for > > SessionType=Discovery? > > Unless I see other objections, I intend to incorporate Bill's > suggestion into the next draft, with one change. Rather than calling > ErrorRecoveryLevel "irrelevant", I prefer to say that the negotiation > of ErrorRecoveryLevel is irrelevant, and the operational > ErrorRecoveryLevel must always be implicitly set to 0 for discovery > sessions. Thank you. Yes, it sounds like you are going to add text which matches what I meant, not what I said; I want to effectively add an "Irrelevant when: SessionType=Discovery" line to section 12.20 of RFC 3720. Take care, Bill --Apple-Mail-1--368386101 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDHyd2DJT2Egh26K0RAhEZAKCTS+3eCPsnpLhUaekKOu79Bu10LgCggjYE RTLybp78ww4aa1oI//LCx54= =QVjc -----END PGP SIGNATURE----- --Apple-Mail-1--368386101-- --===============1669256386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1669256386==-- From ips-bounces@ietf.org Wed Sep 07 13:49:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED438-0005ry-Sv; Wed, 07 Sep 2005 13:49:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED437-0005rt-Ln for ips@megatron.ietf.org; Wed, 07 Sep 2005 13:49:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05620 for ; Wed, 7 Sep 2005 13:49:28 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED46K-0005JK-Bg for ips@ietf.org; Wed, 07 Sep 2005 13:52:49 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id A9DF8870F8; Wed, 7 Sep 2005 13:49:26 -0400 (EDT) In-Reply-To: <431F1250.2060504@rose.hp.com> References: <7D036BD3216A084DB1BD9D62BCEAF29001119E68@mail1irv.inside.istor.com> <17172.41745.260474.196649@gargle.gargle.HOWL> <1125430022.10995.17.camel@duala1.corp.silverbacksystems.com> <431F1250.2060504@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] Data Out PDU's Date: Wed, 7 Sep 2005 10:49:20 -0700 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0759606351==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0759606351== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--368210814" Content-Transfer-Encoding: 7bit --Apple-Mail-2--368210814 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 7, 2005, at 9:16 AM, Mallikarjun C. wrote: > While a literal reading of the text indeed implies what Gwendal says > below, I do not believe that was really the intent of the RFC. The > rest of the paragraph text only discusses R2T handling within a task, > not across tasks. There are a couple of issues with the "must satisfy > R2Ts in order across tasks" interpretation: > > Since other transports, FC and SAS included, do not require in-order > data sequence transfers (on R2T-analogs) across tasks, building bridge > devices becomes complex. > > With virtualizers, each task may in fact be serviced by a different > "real" initiator, so enforcing order across them is complex. > > For these reasons, I intend to clarify in the implementer's guide that > RFC3720's intended servicing order of R2Ts is only within a task but > not across tasks. If you have concerns or questions on this proposed > change, please speak up. I am fine with this change, and feel it reflects what was really intended. Take care, Bill --Apple-Mail-2--368210814 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDHyglDJT2Egh26K0RAvO7AJwLzw3Cim6KRoBr16XR7V1sjxxJCQCcCOox euaH2Bdw6lEM5EmZj/PvnT4= =70MB -----END PGP SIGNATURE----- --Apple-Mail-2--368210814-- --===============0759606351== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0759606351==-- From ips-bounces@ietf.org Thu Sep 08 14:00:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDQhN-0001GK-7j; Thu, 08 Sep 2005 14:00:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDQhI-0001Fb-Jr; Thu, 08 Sep 2005 14:00:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06366; Thu, 8 Sep 2005 14:00:27 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDQkj-00036I-5t; Thu, 08 Sep 2005 14:04:01 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EDQhI-0004qd-8O; Thu, 08 Sep 2005 14:00:28 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 08 Sep 2005 14:00:28 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ips@ietf.org Subject: [Ips] Last Call: 'Definitions of Managed Objects For iFCP' to Proposed Standard X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The IESG has received a request from the IP Storage WG to consider the following document: - 'Definitions of Managed Objects For iFCP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-09-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-mib-06.txt _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 09 17:02:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDq0h-0005tX-MD; Fri, 09 Sep 2005 17:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDq0f-0005tP-Pz for ips@megatron.ietf.org; Fri, 09 Sep 2005 17:02:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09772 for ; Fri, 9 Sep 2005 17:02:07 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDq4H-0001PQ-SK for ips@ietf.org; Fri, 09 Sep 2005 17:05:56 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j89L17FS021327; Fri, 9 Sep 2005 16:01:10 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Sep 2005 23:01:06 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507FC5703@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Mark Bakke , IPS Date: Fri, 9 Sep 2005 23:01:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Cc: Keith McCloghrie , "Allison Mankin \(E-mail\)" Subject: [Ips] RE: Submitted iscsi-mib-10 draft X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Sorry that it took me so long. Summary: I think it would be good to have a new revision that addresses most (if not all) of my comments below. I note that the draft-ietf-ips-auth-mib-06.txt is a normative reference and that one is in status "Revised ID needed" so I am not sure I am supposed to do MIB DOctor review now or wait for a new revision? Bert ----- details of the review - I wonder if this part (from sect 6.16) To avoid sending an excessive number of notifications due to multiple errors counted, an SNMP agent implementing the iSCSI MIB module SHOULD NOT send more than three iSCSI notifications in any 10-second period. Should not be provided somehwer in one or more DESCRIPTION clauses inside the MIB itself. Maybe in the DESCRIPTION clauses of the Notifications them selves. This to ensure that people who implement the notifications WILL see this warning. - smicng tells me: W: f(iscsi.mi2), (2620,9) Duplicate item "iscsiPortalStorageType" in object- group "iscsiPortalAttributesGroup" OBJECTS list The object is just listed twice. Simple to fix - smilint tells me: ./ISCSI-MIB:92: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2 this is for IscsiTransportProtocols TC ./ISCSI-MIB:1064: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2 this is for iscsiNodeErrorRecoveryLevel ./ISCSI-MIB:2128: [5] {integer-misuse} warning: use Integer32 instead of INTEGER in SMIv2 this is for iscsiSsnErrorRecoveryLevel Probably better to use Integer32 - I wonder if IscsiTransportProtocols not better be IscsiTransportProtocol that is singular. Each time it is used for SYNTAX, I think it can only represent ONE SINGLE protocol from the list of valid protocols under iana registration. - When I see this: IscsiName ::= TEXTUAL-CONVENTION DISPLAY-HINT "223a" STATUS current DESCRIPTION "This data type is used to define an iSCSI Name." REFERENCE "iSCSI Protocol Specification, Section 3.2.6, iSCSI Names." SYNTAX OCTET STRING (SIZE(16..223)) Then that REFERENCE looks nice, but I have no idea where to look? Is it RFC3720? If so why not do REFERENCE "RFC3720, iSCSI Protocol Specification, Section 3.2.6, iSCSI Names." If it is that section, then I do see it has a max size of 223 specified in sect 3.2.6.1. I do not see the min size of 16 ?? I suspect it is actually larger than 16 (if I understand all subsections of 3.2.6 correct. It is not a showstopper, I just tried to understand. More important is that (if I understand it all): 3.2.6.2. iSCSI Name Encoding An iSCSI name MUST be a UTF-8 encoding of a string of Unicode characters with the following properties: So should the TC above not say something about it being UTF8? Maybe it should be a Utf8String as defined in SysApplMib (RFC2287) In any event, it would be important to indicate if the names in an OBJECT of this SYNTAX have gone through normalization (stringprep) or not. Or so I think. The DISPLAY-HINT "223a" seems to indicate that the OCTET STRING is a ASCII string, but I doubt it is based on my reading of rfc3720. If the string is UTF-8 (as I understand it to be) then the DISPLAY-HINT "223t" should be used as per bullet 3, page 22 of RFC2579. Further I see that when you actually use this TC to specify the SYNTAX of an object that one time you have DESCRIPTION iscsiInstLastSsnRmtNodeName DESCRIPTION "An octet string describing the name of the remote node and anotehr time a DESCRIPTION iscsiNodeName DESCRIPTION "A character string that is a globally unique identifier for this iSCSI node. The node name is independent of the location and another time a DESCRIPTION iscsiTgtLastIntrFailureName DESCRIPTION "An octet string giving the name of the initiator that failed the last login attempt." which just makes it all more confusing. I.e. is it an octet or a character string. Is it UTF-8 or ASCII? Or what? The idea of a TC is to have one single DESCRIPTION of th esemantics of the object type (or so I think). - Is there any discontinuity timer for: iscsiInstSsnFailures? I think it is this one: iscsiInstDiscontinuityTime But it needs to be specified in the DESCRIPTION clause of each Counter32/Counter64 as per RFC2578 sect 7.1.6 Pls check for other Counter32/Counter5=64 objects as well. I would not be so explicit in the DESCRIPTION clause of iscsiInstDiscontinuityTime itself. It makes it harder to use that same timer for future Counterxx objects. - I see iscsiPortalAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The portal's Internet Network Address." Formally the DESCRIPTION clause MUST indicate which InetAddressType object is used to define the format of this object. Also... is DNS possible? If so, one MUST specify when the dns name is to be resolved. Pls check this for all occurences of InetAddress - I see iscsiNodeInitialR2T OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the InitialR2T preference for this node: True = YES, False = will try to negotiate NO, will accept YES " nit: I would use all lowercase for 'true' and 'false' since that are the labels for TruthValue Similar remark for other cases where a TruthValue is used for SYNTAX - For the read-write objects in iscsiNodeAttributesTable I do not see any text that explains the required/expected persistence behaviour? Pls check that such behaviour is documented for all writable (read-create and read-write) objects. - When I see iscsiNodeErrorRecoveryLevel OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The ErrorRecoveryLevel preference of this node. Currently, only 0-2 are valid. This object is designed to accommodate future error recover levels. Then I wonder if you want to specify that 0-2 are only valid now in the MODULE-COMPLIANCE, or in other words, ensure that a implementation can claim compliance if they only support 0-2 now. - I see: iscsiSsnInitiatorName OBJECT-TYPE SYNTAX IscsiName MAX-ACCESS read-only STATUS current DESCRIPTION "If iscsiSsnDirection is Inbound, this object is an octet string that will contain the name of the remote initiator. If this session is a discovery session that does not specify a particular initiator, this object will contain a zero-length string. If iscsiSsnDirection is Outbound, this object will contain a zero-length string." But the SYNTAX clause of the IscsiName TEXTUAL CONVENTION says: SYNTAX OCTET STRING (SIZE(16..223)) SO a zero length string seems to be in conflict with that. - iscsiSsnInitiatorAlias OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "An octet string that gives the alias communicated by the initiator end of the session during the login phase. Mmm... "An octet string" may confuse people. SnmpAdminString is a UTF-8 string. Same for: iscsiSsnTargetAlias - When I see: iscsiCxnLocalAddrType InetAddressType, iscsiCxnLocalAddr InetAddress, iscsiCxnProtocol IscsiTransportProtocols, iscsiCxnLocalPort InetPortNumber, iscsiCxnRemoteAddrType InetAddressType, iscsiCxnRemoteAddr InetAddress, Then I always wonder oif the iscsiCxnLocalAddr and iscsiCxnRemoteAddr MUST be of the same InetAddressType. If so, then you only need to have one such InetAddressType object and probably that is what you want in that case, because it makes it easier to ensure that both address types are the same. See also my earlier remakrs about InetAddress (i.e. need to state which InetAddresType object specifies the format and need to say when DNS names are resolved (if they are valid types). - iscsiCxnLocalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The local transport protocol port used by this connection." According to RFC3291 (now obsoleted by RFC4001 by the way) you MUST describe what the meaning is of a portnuumber value zero. same for iscsiCxnRemotePort - I do not understand why you do: iscsiNotifications OBJECT IDENTIFIER ::= { iscsiMibModule 0 } ... iscsiNotificationsPrefix OBJECT IDENTIFIER ::= { iscsiNotifications 0 } cause that gives you an OID for notifications that ends in 0.0.x and that I think we do not want. So I would just root the notifications under iscsiNotifications and forget about the xxxPrefix. - I see comment lines like: ------------------------------------------------------------------ They are OK but I find them dangerous, cause they MUST be a multiple of two dashes othersise it causes trouble. If you need/want a separator line I prefer to see: --**************************************************************** - I see: iscsiComplianceV1 MODULE-COMPLIANCE STATUS current DESCRIPTION "Initial version of compliance statement based on initial version of this MIB module. If an implementation can be both a target and an initiator, all groups are mandatory." In principle there is nothing wrong. I personally always wonder if it does not make more sense to make that 2 Compliances, one for targets and one for initiators. It makes it much easier to specify compliance in "mandatory groups" as opposed to large sets of optional or conditionally optional groups. - You have the SCSIMIB as Informative reference. But you have RowPointer(s) pointing to entries in that MIB module, so to me that sort of indicates it is a normative reference, no? Just for completeness: $ idnits draft-ietf-ips-iscsi-mib-10.txt idnits 1.77 (21 Aug 2005) draft-ietf-ips-iscsi-mib-10.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Bert > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Sunday, February 20, 2005 20:35 > To: IPS > Cc: Bert Wijnen; Keith McCloghrie > Subject: Submitted iscsi-mib-10 draft > > > > I've just submitted iscsi-mib-10 as an internet draft, to address MIB > Doctor review > comments as well as clean up a few things. Until it pops out of the > draft queue, it's > available in: > > ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/ > > A new UML model showing the one update to the MIB structure > (the addition of a node index to the initiator and target portal > structure to address comments from long ago) is also available in > the same location, along with the plain .mi2 for compiling, and > diffs of the MIB module itself from -09. > > Thanks to Jim Muchow, Keith McCloghrie, and Marjorie Krueger > for help in working through this last set of edits, and to Bert > Wijnen (MIB Doctor) for his constructive (and educational, for > me anyway) comments. > > Major changes to this module are: > > - The addition of node index to initiator and target portals > - The addition of StorageType objects > - Better text for all RowStatus objects > - Better text for all Index objects > - Addition of DiscontinuityTime objects for instances and nodes > - Improved SNMP terminology throughout > - Some renumbering of higher-level objects was necessary to > make use of more standard numbering schemes and to add > the index values on the portals > - A large number of REFERENCE statements were added > - Changed objects from INTEGER to Unsigned32 except for enums > - Renamed iscsiSsnDigestErrors to iscsiSsnCxnDigestErrors > > As there were quite a few changes to this document, it is very likely > that I've either missed something in the editing, or perhaps have not > completely addressed the review comments. Please let me know > if there's anything missing. > > Thanks, > > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 952-967-8374 > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 09 20:22:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDt8k-0000JW-6S; Fri, 09 Sep 2005 20:22:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDt8j-0000J2-5u for ips@megatron.ietf.org; Fri, 09 Sep 2005 20:22:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23913 for ; Fri, 9 Sep 2005 20:22:39 -0400 (EDT) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDtCP-0007cz-Co for ips@ietf.org; Fri, 09 Sep 2005 20:26:29 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 2571F218A for ; Fri, 9 Sep 2005 20:22:37 -0400 (EDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.112]) by rosemail.rose.hp.com (Postfix) with ESMTP id 5227E8051 for ; Fri, 9 Sep 2005 17:19:28 -0700 (PDT) Message-ID: <43222746.5060309@rose.hp.com> Date: Fri, 09 Sep 2005 17:22:30 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS References: <4209e5cc97cf74b05afedffc257cdff3@wasabisystems.com> <431F149A.7060500@rose.hp.com> In-Reply-To: <431F149A.7060500@rose.hp.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Subject: [Ips] Discovery text X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > On the main discovery thread, thanks for all the feedback. I intend t= o > propose some specific text to the list in the next few days. > The new proposed text is attached below. I intend to shortly publish a -01 revision with several updates,=20 including this one subject to agreement (which I hope exists based on=20 the threads so far....). Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com 5 Discovery semantics 5.1 Error Recovery for Discovery Sessions The negotiation of the key ErrorRecoveryLevel is irrelevant for=20 Discovery sessions =E2=80=93 i.e. for sessions that negotiated=20 =E2=80=9CSessionType=3DDiscovery=E2=80=9D. The operational ErrorRecovery= Level for=20 Discovery sessions MUST be 0. This naturally follows from the=20 functionality constraints [RFC3720] imposes on Discovery sessions. 5.2 Discovery Philosophy and Reinstatement Discovery sessions are intended to be relatively short-lived.=20 Initiators are not expected to establish multiple Discovery sessions to=20 the same iSCSI Portal (see [RFC3720]). An initiator may use the same=20 iSCSI Initiator Name and ISID when establishing different unique=20 sessions with different targets and/or different portal groups. This=20 behavior is discussed in Section 9.1.1 of [RFC3720] and is, in fact,=20 encouraged as conservative reuse of ISIDs. ISID RULE in [RFC3720]=20 states that there must not be more than one session with a matching=20 4-tuple: . While=20 the spirit of the ISID RULE applies to Discovery sessions the same as it=20 does for Normal sessions, note that some Discovery sessions differ from=20 the Normal sessions in two important aspects: =EF=80=AA Because [RFC3720] allows a Discovery session to be established = without=20 specifying a TargetName key in the Login Request PDU (let us call such a=20 session an =E2=80=9CUnnamed=E2=80=9D Discovery session), there is no Targ= et Node context=20 to enforce the ISID RULE. =EF=80=AA Portal Groups are defined only in the context of a Target Node.= When=20 the TargetName key is NULL-valued (i.e. not specified), the=20 TargetPortalGroupTag thus cannot be ascertained to enforce the ISID RULE. The following sections describe the two scenarios =E2=80=93 Named Discove= ry=20 sessions and Unnamed Discovery sessions =E2=80=93 separately. 5.2.1 Unnamed Discovery Sessions For Unnamed Discovery sessions, neither the TargetName nor the=20 TargetPortalGroupTag is available to the targets in order to enforce the=20 ISID RULE. So the following rule applies. UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the following=20 4-tuple for Unnamed Discovery sessions: . The following semantics are implied by this uniqueness=20 requirement. Resources permitting, targets MUST allow concurrent establishment of one=20 Discovery session with each of its Portals by the same initiator port=20 with a given iSCSI Node Name and an ISID. Each of the concurrent=20 Discovery sessions, if established by the same initiator port, MUST be=20 treated as independent sessions =E2=80=93 i.e. one session MUST NOT reins= tate=20 the other. A new Unnamed Discovery session that has a matching to an existing discovery session MUST=20 reinstate the existing Unnamed Discovery session. Note thus that only=20 an Unnamed Discovery session may reinstate an Unnamed Discovery session. 5.2.2 Named Discovery Sessions For a Named Discovery session, the TargetName key is specified by the=20 initiator and thus the target can unambiguously ascertain the=20 TargetPortalGroupTag as well. Since all the four elements of the=20 4-tuple are known, the ISID RULE MUST be enforced by targets with no=20 changes from [RFC3720] semantics. A new session with a matching=20 thus will=20 reinstate an existing session. Note in this case that any new iSCSI=20 session (Discovery or Normal) with the matching 4-tuple may reinstate an=20 existing Named Discovery iSCSI session. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Sep 11 20:50:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEcWo-0001aG-Cs; Sun, 11 Sep 2005 20:50:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEcWi-0001Yp-NS for ips@megatron.ietf.org; Sun, 11 Sep 2005 20:50:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02711 for ; Sun, 11 Sep 2005 20:50:14 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEcac-00023h-Cq for ips@ietf.org; Sun, 11 Sep 2005 20:54:30 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 0F5BD87087; Sun, 11 Sep 2005 20:50:01 -0400 (EDT) In-Reply-To: <43222746.5060309@rose.hp.com> References: <4209e5cc97cf74b05afedffc257cdff3@wasabisystems.com> <431F149A.7060500@rose.hp.com> <43222746.5060309@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <145951d1fd1b4322ad98fbdc9d05ed96@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery text Date: Sun, 11 Sep 2005 17:49:53 -0700 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1374288567==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1374288567== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-2621522" Content-Transfer-Encoding: 7bit --Apple-Mail-1-2621522 Content-Type: text/plain; charset=Big5-HKSCS; format=flowed Content-Transfer-Encoding: quoted-printable On Sep 9, 2005, at 5:22 PM, Mallikarjun C. wrote: > The new proposed text is attached below. I have a minor comment (below), but overall, LOOKS GREAT! > I intend to shortly publish a -01 revision with several updates,=20 > including this one subject to agreement (which I hope exists based on=20= > the threads so far....). > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > 5 Discovery semantics > 5.1 Error Recovery for Discovery Sessions > The negotiation of the key ErrorRecoveryLevel is irrelevant for=20 > Discovery sessions =A1V i.e. for sessions that negotiated=20 > =A1=A7SessionType=3DDiscovery=A1=A8. The operational = ErrorRecoveryLevel for=20 > Discovery sessions MUST be 0. This naturally follows from the=20 > functionality constraints [RFC3720] imposes on Discovery sessions. > > 5.2 Discovery Philosophy and Reinstatement > Discovery sessions are intended to be relatively short-lived.=20 > Initiators are not expected to establish multiple Discovery sessions=20= > to the same iSCSI Portal (see [RFC3720]). An initiator may use the=20 > same iSCSI Initiator Name and ISID when establishing different unique=20= > sessions with different targets and/or different portal groups. This=20= > behavior is discussed in Section 9.1.1 of [RFC3720] and is, in fact,=20= > encouraged as conservative reuse of ISIDs. ISID RULE in [RFC3720]=20 > states that there must not be more than one session with a matching=20 > 4-tuple: . =20 > While the spirit of the ISID RULE applies to Discovery sessions the=20 > same as it does for Normal sessions, note that some Discovery sessions=20= > differ from the Normal sessions in two important aspects: > =83x Because [RFC3720] allows a Discovery session to be established=20= > without specifying a TargetName key in the Login Request PDU (let us=20= > call such a session an =A1=A7Unnamed=A1=A8 Discovery session), there = is no=20 > Target Node context to enforce the ISID RULE. > =83x Portal Groups are defined only in the context of a Target Node. =20= > When the TargetName key is NULL-valued (i.e. not specified), the=20 > TargetPortalGroupTag thus cannot be ascertained to enforce the ISID=20 > RULE. > > The following sections describe the two scenarios =A1V Named Discovery=20= > sessions and Unnamed Discovery sessions =A1V separately. > > 5.2.1 Unnamed Discovery Sessions > For Unnamed Discovery sessions, neither the TargetName nor the=20 > TargetPortalGroupTag is available to the targets in order to enforce=20= > the ISID RULE. So the following rule applies. > > UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the=20 > following 4-tuple for Unnamed Discovery sessions: ISID, NULL, TargetAddress>. The following semantics are implied by=20 > this uniqueness requirement. > > Resources permitting, targets MUST allow concurrent establishment of=20= > one Discovery session with each of its I'm not sure if we're supposed to use "MUST" like this. I think=20 "SHOULD" is the correct word; we definitely think the target must do=20 this, but realize there may be an occasion in which it can't. > Portals by the same initiator port with a given iSCSI Node Name and an=20= > ISID. Each of the concurrent Discovery sessions, if established by=20 > the same initiator port, MUST be treated as independent sessions =A1V=20= > i.e. one session MUST NOT reinstate the other. > > A new Unnamed Discovery session that has a matching ISID, NULL, TargetAddress> to an existing discovery session MUST=20 > reinstate the existing Unnamed Discovery session. Note thus that only=20= > an Unnamed Discovery session may reinstate an Unnamed Discovery=20 > session. > > 5.2.2 Named Discovery Sessions > For a Named Discovery session, the TargetName key is specified by the=20= > initiator and thus the target can unambiguously ascertain the=20 > TargetPortalGroupTag as well. Since all the four elements of the=20 > 4-tuple are known, the ISID RULE MUST be enforced by targets with no=20= > changes from [RFC3720] semantics. A new session with a matching=20 > thus will=20 > reinstate an existing session. Note in this case that any new iSCSI=20= > session (Discovery or Normal) with the matching 4-tuple may reinstate=20= > an existing Named Discovery iSCSI session. Take care, Bill --Apple-Mail-1-2621522 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDJNC2DJT2Egh26K0RAoXwAJoCwDAJ3ZFAdg8CDUvBRHZVUvAeuACbBZ+5 xbS/Tv4qvx+ym01u9ol0rzY= =ZpOM -----END PGP SIGNATURE----- --Apple-Mail-1-2621522-- --===============1374288567== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1374288567==-- From ips-bounces@ietf.org Sun Sep 11 21:13:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEcsu-0004vk-IT; Sun, 11 Sep 2005 21:13:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEcss-0004vI-Fx for ips@megatron.ietf.org; Sun, 11 Sep 2005 21:13:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03464 for ; Sun, 11 Sep 2005 21:13:15 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEcws-0002Vt-Ly for ips@ietf.org; Sun, 11 Sep 2005 21:17:31 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id CEE3B8708A for ; Sun, 11 Sep 2005 21:13:14 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <297a7bedb67c09d13f41f7312b8d051a@wasabisystems.com> To: IPS From: William Studenmund Date: Sun, 11 Sep 2005 18:13:08 -0700 X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Ips] Unlikely scenario case about SNACK retransmission X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0903058596==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0903058596== Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-4016895" --Apple-Mail-2-4016895 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Say the target is in the process of retransmitting PDUs in response to a SNACK request. Say for the sake of discussion, it "takes a while"; the time to retransmit is long compared to other things in the session. Now say that while this is happening, the initiator adjusts its MaxRecvDataSegmentLength. What should the target do? My main interest is in the case where MaxRecvDataSegmentLength decreases, causing the sent PDUs to be smaller than before. Thus the target can't simultaneously retransmit the PDUs as before and honor MaxRecvDataSegmentLength. I'd however like to come up with something consistent for the MaxRecvDataSegmentLength increases case as we only discuss resegmentation in other parts of the spec, not resegmentation to smaller PDUs. Thoughts on what to do: 1) Consider retransmission to be atomic, and just send the PDUs as-sent. The thought here is that the retransmission code doesn't "notice" the resegmentation while it's in the middle of sending. 2) Stop retransmitting. Reasonable, but I'm not sure how to inform the initiator why we stopped. Reject the SNACK Request PDU even though we started responding to it? 3) Abort the task with a "target out of resources" type error; something where the initiator knows it can retry the command. This option seems rather drastic, but it is a good "get out of the corner we're painted in" type option. Take care, Bill --Apple-Mail-2-4016895 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDJNYqDJT2Egh26K0RAnNbAJ4h/ZxGIG1KE1tq19+Kqu4Ck723CgCeKE/O gcz2xnDva0Cl9M0+8x5lkbE= =dlZm -----END PGP SIGNATURE----- --Apple-Mail-2-4016895-- --===============0903058596== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0903058596==-- From ips-bounces@ietf.org Mon Sep 12 04:37:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEjog-0003hc-Oj; Mon, 12 Sep 2005 04:37:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEjoS-0003dF-40 for ips@megatron.ietf.org; Mon, 12 Sep 2005 04:37:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03996 for ; Mon, 12 Sep 2005 04:37:02 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEjsO-0004No-Kh for ips@ietf.org; Mon, 12 Sep 2005 04:41:22 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8C8aFOI046244 for ; Mon, 12 Sep 2005 08:36:17 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8C8aFIj159530 for ; Mon, 12 Sep 2005 10:36:15 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8C8aEpl011089 for ; Mon, 12 Sep 2005 10:36:15 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8C8aAWi010991; Mon, 12 Sep 2005 10:36:13 +0200 In-Reply-To: <297a7bedb67c09d13f41f7312b8d051a@wasabisystems.com> To: William Studenmund Subject: Re: [Ips] Unlikely scenario case about SNACK retransmission MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Mon, 12 Sep 2005 11:36:09 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 12/09/2005 11:36:12 Content-Type: multipart/mixed; boundary="=_mixed 002EF40CC225707A_=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --=_mixed 002EF40CC225707A_= Content-Type: multipart/alternative; boundary="=_alternative 002EF40CC225707A_=" --=_alternative 002EF40CC225707A_= Content-Type: text/plain; charset="US-ASCII" This scenario has been taken care in the text of RFC3720. The retransmitted data PDUs do not have have to be the same as the original ones and the new length should be used by the target. The only think that is "forbidden" is to ask for data that is prior to the last ack point. Julo William Studenmund Sent by: ips-bounces@ietf.org 12-09-05 04:13 To IPS cc Subject [Ips] Unlikely scenario case about SNACK retransmission Say the target is in the process of retransmitting PDUs in response to a SNACK request. Say for the sake of discussion, it "takes a while"; the time to retransmit is long compared to other things in the session. Now say that while this is happening, the initiator adjusts its MaxRecvDataSegmentLength. What should the target do? My main interest is in the case where MaxRecvDataSegmentLength decreases, causing the sent PDUs to be smaller than before. Thus the target can't simultaneously retransmit the PDUs as before and honor MaxRecvDataSegmentLength. I'd however like to come up with something consistent for the MaxRecvDataSegmentLength increases case as we only discuss resegmentation in other parts of the spec, not resegmentation to smaller PDUs. Thoughts on what to do: 1) Consider retransmission to be atomic, and just send the PDUs as-sent. The thought here is that the retransmission code doesn't "notice" the resegmentation while it's in the middle of sending. 2) Stop retransmitting. Reasonable, but I'm not sure how to inform the initiator why we stopped. Reject the SNACK Request PDU even though we started responding to it? 3) Abort the task with a "target out of resources" type error; something where the initiator knows it can retry the command. This option seems rather drastic, but it is a good "get out of the corner we're painted in" type option. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 002EF40CC225707A_= Content-Type: text/html; charset="US-ASCII"
This scenario has been taken care in the text of RFC3720.
The retransmitted data PDUs do not have have to be the same as the original ones and the new length should be used by the target.
The only think that is "forbidden" is to ask for data that is prior to the last ack point.

Julo




William Studenmund <wrstuden@wasabisystems.com>
Sent by: ips-bounces@ietf.org

12-09-05 04:13

To
IPS <ips@ietf.org>
cc
Subject
[Ips] Unlikely scenario case about SNACK retransmission





Say the target is in the process of retransmitting PDUs in response to
a SNACK request. Say for the sake of discussion, it "takes a while";
the time to retransmit is long compared to other things in the session.
Now say that while this is happening, the initiator adjusts its
MaxRecvDataSegmentLength. What should the target do?

My main interest is in the case where MaxRecvDataSegmentLength
decreases, causing the sent PDUs to be smaller than before. Thus the
target can't simultaneously retransmit the PDUs as before and honor
MaxRecvDataSegmentLength.

I'd however like to come up with something consistent for the
MaxRecvDataSegmentLength increases case as we only discuss
resegmentation in other parts of the spec, not resegmentation to
smaller PDUs.

Thoughts on what to do:

1) Consider retransmission to be atomic, and just send the PDUs
as-sent. The thought here is that the retransmission code doesn't
"notice" the resegmentation while it's in the middle of sending.

2) Stop retransmitting. Reasonable, but I'm not sure how to inform the
initiator why we stopped. Reject the SNACK Request PDU even though we
started responding to it?

3) Abort the task with a "target out of resources" type error;
something where the initiator knows it can retry the command. This
option seems rather drastic, but it is a good "get out of the corner
we're painted in" type option.

Take care,

Bill
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 002EF40CC225707A_=-- --=_mixed 002EF40CC225707A_= Content-Type: application/octet-stream; name="PGP.sig" Content-Disposition: attachment; filename="PGP.sig" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAoRGFy d2luKQ0KDQppRDhEQlFGREpOWXFESlQyRWdoMjZLMFJBbk5iQUo0aC9aeEdJRzFLRTF0cTE5K0tx dTRDazcyM0NnQ2VLRS9PDQpnY3oyeG5EdmEwQ2w5TTArOHg1bGtiRT0NCj1kbFptDQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --=_mixed 002EF40CC225707A_= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_mixed 002EF40CC225707A_=-- From ips-bounces@ietf.org Mon Sep 12 10:17:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEp4A-00058R-0R; Mon, 12 Sep 2005 10:13:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEp48-000560-3j for ips@megatron.ietf.org; Mon, 12 Sep 2005 10:13:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20431 for ; Mon, 12 Sep 2005 10:13:38 -0400 (EDT) Received: from [64.238.111.98] (helo=thoth.ivivity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEp8C-0004kr-2T for ips@ietf.org; Mon, 12 Sep 2005 10:18:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Sep 2005 10:13:30 -0400 Message-ID: <0F31272A2BCBBE4FA01344C6E69DBF50295F67@thoth.ivivity.com> Thread-Topic: [Ips] Welcome to the new IETF WG list Thread-Index: AcN9Jg9IZkb/xhZJR+mdwdT8At8214Rg/0rgAn+LH4A= From: "Sanjay Goyal" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Subject: [Ips] MPA layer connection setup examples for iSER X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi, draft-ietf-ips-iser-04.txt mentions it is iSCSI over RDMAP.=20 It also shows under Normative references that for MPA, the reference is = draft-ietf-rddp-mpa-02.txt. What I want to know is that, will iSER use the above mentioned MPA draft = as is for MPA layer or it will use subset of the draft. Why I am asking = it is that the MPA draft mentions exchange of MPA Request/Response = Frames before moving to Full operation phase whereas iSER draft says = after Hello exchanges the connection/session should move to iSER = assisted mode or RDMAP mode. Can somebody please post example of connection setup for RDMAP/DDP/MPA = combination. Regards Sanjay _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 12 12:35:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErHL-0007pk-NJ; Mon, 12 Sep 2005 12:35:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErHJ-0007pK-UT for ips@megatron.ietf.org; Mon, 12 Sep 2005 12:35:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00129 for ; Mon, 12 Sep 2005 12:35:29 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EErLT-0000wX-No for ips@ietf.org; Mon, 12 Sep 2005 12:39:54 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8CGZJNp032376 for ; Mon, 12 Sep 2005 12:35:19 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8CGZJj0099320 for ; Mon, 12 Sep 2005 12:35:19 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8CGZJvU003576 for ; Mon, 12 Sep 2005 12:35:19 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8CGZJgD003573; Mon, 12 Sep 2005 12:35:19 -0400 In-Reply-To: <0F31272A2BCBBE4FA01344C6E69DBF50295F67@thoth.ivivity.com> Importance: Normal MIME-Version: 1.0 To: "Sanjay Goyal" Subject: Re: [Ips] MPA layer connection setup examples for iSER X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Mon, 12 Sep 2005 09:35:17 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0HF2 | September 9, 2005) at 09/12/2005 12:35:19, Serialize complete at 09/12/2005 12:35:19 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org When iSER is layered over iWARP, it will utilize MPA as defined. An example of how an iSER connection is setup using iWARP can be found in figure 8 on page 33 of the MPA draft. Note that the "ULP streaming mode request" refers to the final iSCSI Login Request with the T-bit set to 1; and the "last (optional) streaming mode " refers to the final iSCSI Login Response PDU with T-bit set to 1. The "first FPDU (as DDP ULPDUs become available)" to be sent by the MPA layer at the initiator is the iSER Hello Message. Likewise, the iSER HelloReply Message is the "first FPDU" sent by the target after it receives the iSER Hello Message. Mike Sent by: ips-bounces@ietf.org To: cc: Subject: [Ips] MPA layer connection setup examples for iSER Hi, draft-ietf-ips-iser-04.txt mentions it is iSCSI over RDMAP. It also shows under Normative references that for MPA, the reference is draft-ietf-rddp-mpa-02.txt. What I want to know is that, will iSER use the above mentioned MPA draft as is for MPA layer or it will use subset of the draft. Why I am asking it is that the MPA draft mentions exchange of MPA Request/Response Frames before moving to Full operation phase whereas iSER draft says after Hello exchanges the connection/session should move to iSER assisted mode or RDMAP mode. Can somebody please post example of connection setup for RDMAP/DDP/MPA combination. Regards Sanjay _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 12 13:18:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErww-00017s-MM; Mon, 12 Sep 2005 13:18:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErwv-00017U-Be for ips@megatron.ietf.org; Mon, 12 Sep 2005 13:18:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02968 for ; Mon, 12 Sep 2005 13:18:22 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEs0z-0002OT-Pq for ips@ietf.org; Mon, 12 Sep 2005 13:22:48 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id CA9B787093; Mon, 12 Sep 2005 13:18:06 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <2a985e8e0ed7248fcbf30704f2464ee8@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Unlikely scenario case about SNACK retransmission Date: Mon, 12 Sep 2005 10:17:57 -0700 To: Julian Satran X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1543208980==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1543208980== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-61906204" Content-Transfer-Encoding: 7bit --Apple-Mail-1-61906204 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 12, 2005, at 1:36 AM, Julian Satran wrote: > This scenario has been taken care in the text of RFC3720. > The retransmitted data PDUs do not have have to be the same as the > original ones and the new length should be used by the target. > The only think that is "forbidden" is to ask for data that is prior to > the last ack point. Oh. Now I see what you mean. Looking in section 10.16, I see: The numbered Data-In PDUs, requested by a Data SNACK MUST be delivered as exact replicas of the ones that the target transmitted originally except for the fields ExpCmdSN and MaxCmdSN, which MUST carry the current values and except for resegmentation (see Section 10.16.3 Resegmentation). which I now take as meaning that if we are in a Data SNACK and notice resegmentation, we are free to change the size of the PDUs. If I am correct in this interpretation, I think we may want a comment about this as "and except for resegmentation." is not clear grammar. Take care, Bill --Apple-Mail-1-61906204 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDJbhLDJT2Egh26K0RArNMAJ9Tt16IRzkZLUbCBEWMDuQ4rpcHiACdEP56 7krtzcOYaSsDTbKwaL5eP9g= =pLt2 -----END PGP SIGNATURE----- --Apple-Mail-1-61906204-- --===============1543208980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1543208980==-- From ips-bounces@ietf.org Tue Sep 13 16:45:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHem-0007i3-7R; Tue, 13 Sep 2005 16:45:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFHej-0007bp-7X for ips@megatron.ietf.org; Tue, 13 Sep 2005 16:45:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25246 for ; Tue, 13 Sep 2005 16:45:26 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFHjA-0000Rf-5R for ips@ietf.org; Tue, 13 Sep 2005 16:50:06 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j8DKjBij016359 for ; Tue, 13 Sep 2005 16:45:11 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j8DKjBje016354 for ; Tue, 13 Sep 2005 16:45:11 -0400 Received: from pkoning.equallogic.com ([172.16.1.181]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 16:45:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17191.14934.386438.244953@gargle.gargle.HOWL> Date: Tue, 13 Sep 2005 16:45:10 -0400 From: Paul Koning To: ips@ietf.org X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 13 Sep 2005 20:45:11.0592 (UTC) FILETIME=[090CFA80:01C5B8A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Ips] task aborts, r2t, and the F bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The spec in the discussion of task management says (page 129) that an initiator MUST continue to respond to things like R2T after issuing an Abort Task Set command. But it is encouraged to make things finish faster by sending F=1 in its responses. That sounds reasonable... if you're trying to abort a write, it would be good not to have to send that 2 megabytes of data you tried to write. However, the description of R2T clearly says that sending F=1 in a DataOut at any byte count other than the exact byte count requested in the R2T is an error. So... did I misunderstand, and you really do have to send all the write data for a write being aborted? Or is the R2T rule supposed to apply only when the task isn't being aborted? paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 13 19:02:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFJng-0000t3-GT; Tue, 13 Sep 2005 19:02:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFJne-0000mp-S6 for ips@megatron.ietf.org; Tue, 13 Sep 2005 19:02:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06218 for ; Tue, 13 Sep 2005 19:02:46 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFJs6-0005D2-Oj for ips@ietf.org; Tue, 13 Sep 2005 19:07:29 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id B849087089; Tue, 13 Sep 2005 19:02:36 -0400 (EDT) In-Reply-To: <17191.14934.386438.244953@gargle.gargle.HOWL> References: <17191.14934.386438.244953@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <3a2c99f70181b39eac32f5fed47fb2c1@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] task aborts, r2t, and the F bit Date: Tue, 13 Sep 2005 16:02:29 -0700 To: Paul Koning X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1392540186==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1392540186== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-168977394" Content-Transfer-Encoding: 7bit --Apple-Mail-3-168977394 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 13, 2005, at 1:45 PM, Paul Koning wrote: > The spec in the discussion of task management says (page 129) that an > initiator MUST continue to respond to things like R2T after issuing an > Abort Task Set command. But it is encouraged to make things finish > faster by sending F=1 in its responses. > > That sounds reasonable... if you're trying to abort a write, it would > be good not to have to send that 2 megabytes of data you tried to > write. > > However, the description of R2T clearly says that sending F=1 in a > DataOut at any byte count other than the exact byte count requested in > the R2T is an error. > > So... did I misunderstand, and you really do have to send all the > write data for a write being aborted? Or is the R2T rule supposed to > apply only when the task isn't being aborted? As a target implementer I took the R2T rule to only apply when the task is healthy. If it's being aborted, it's ok to finish a target task early. Take care, Bill --Apple-Mail-3-168977394 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDJ1qLDJT2Egh26K0RAjxMAJ9FpBljI0S0QqV9XoP5bVn8CJuFbwCdFRkB m7zMtcAoR1o0D2t1/TLW5z0= =XvSq -----END PGP SIGNATURE----- --Apple-Mail-3-168977394-- --===============1392540186== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1392540186==-- From ips-bounces@ietf.org Wed Sep 14 08:23:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFWIB-00047I-DN; Wed, 14 Sep 2005 08:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFWIA-00047A-GX for ips@megatron.ietf.org; Wed, 14 Sep 2005 08:23:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07328 for ; Wed, 14 Sep 2005 08:23:09 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFWMi-0000OI-MF for ips@ietf.org; Wed, 14 Sep 2005 08:27:56 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8ECMnO0011192 for ; Wed, 14 Sep 2005 12:22:49 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8ECMm16158348 for ; Wed, 14 Sep 2005 14:22:48 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8ECMmq6010242 for ; Wed, 14 Sep 2005 14:22:48 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8ECMmZR010236; Wed, 14 Sep 2005 14:22:48 +0200 In-Reply-To: <17191.14934.386438.244953@gargle.gargle.HOWL> To: Paul Koning Subject: Re: [Ips] task aborts, r2t, and the F bit MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Wed, 14 Sep 2005 15:22:46 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 14/09/2005 15:22:47, Serialize complete at 14/09/2005 15:22:47 X-Spam-Score: 0.5 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0413799544==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0413799544== Content-Type: multipart/alternative; boundary="=_alternative 0043E87EC225707C_=" This is a multipart message in MIME format. --=_alternative 0043E87EC225707C_= Content-Type: text/plain; charset="US-ASCII" Paul, The rule about the R2T was meant for the case the target issued some R2Ts before receiving or acting on abort. In this case a target may want to have all its R2T accounted for before it finishes the abort. The data have to be all there if the initiator can't ascertain that the data will be received after the abort is initiated. I assumed that when the initiator can be certain the data will be seen after the abort (e.g., they come on the same connection) it may ignore the "completeness" rule. It should also be possible to ignore the rule unilaterally (at the initiator) but then the "SCSI" part of the initiator should be prepared to act on errors resulting from this behavior. Julo Paul Koning Sent by: ips-bounces@ietf.org 13-09-05 23:45 To ips@ietf.org cc Subject [Ips] task aborts, r2t, and the F bit The spec in the discussion of task management says (page 129) that an initiator MUST continue to respond to things like R2T after issuing an Abort Task Set command. But it is encouraged to make things finish faster by sending F=1 in its responses. That sounds reasonable... if you're trying to abort a write, it would be good not to have to send that 2 megabytes of data you tried to write. However, the description of R2T clearly says that sending F=1 in a DataOut at any byte count other than the exact byte count requested in the R2T is an error. So... did I misunderstand, and you really do have to send all the write data for a write being aborted? Or is the R2T rule supposed to apply only when the task isn't being aborted? paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0043E87EC225707C_= Content-Type: text/html; charset="US-ASCII"
Paul,

The rule about the R2T was meant for the case the target issued some R2Ts before receiving or acting on abort.
In this case a target may want to have all its R2T accounted for before it finishes the abort.

The data have to be all there if the initiator can't ascertain that the data will be received after the abort is initiated.

I assumed that when the initiator can be certain the data will be seen after the abort (e.g., they come on the same connection) it may ignore the "completeness" rule.
It should also be possible to ignore the rule unilaterally (at the initiator) but then the "SCSI" part of the initiator should be prepared to act on errors resulting from this behavior.

Julo




Paul Koning <pkoning@equallogic.com>
Sent by: ips-bounces@ietf.org

13-09-05 23:45

To
ips@ietf.org
cc
Subject
[Ips] task aborts, r2t, and the F bit





The spec in the discussion of task management says (page 129) that an
initiator MUST continue to respond to things like R2T after issuing an
Abort Task Set command.  But it is encouraged to make things finish
faster by sending F=1 in its responses.

That sounds reasonable... if you're trying to abort a write, it would
be good not to have to send that 2 megabytes of data you tried to
write.

However, the description of R2T clearly says that sending F=1 in a
DataOut at any byte count other than the exact byte count requested in
the R2T is an error.

So... did I misunderstand, and you really do have to send all the
write data for a write being aborted?  Or is the R2T rule supposed to
apply only when the task isn't being aborted?

     paul


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 0043E87EC225707C_=-- --===============0413799544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0413799544==-- From ips-bounces@ietf.org Wed Sep 14 11:01:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYlT-0007U5-3w; Wed, 14 Sep 2005 11:01:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFYlR-0007Tx-P3 for ips@megatron.ietf.org; Wed, 14 Sep 2005 11:01:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15707 for ; Wed, 14 Sep 2005 11:01:31 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFYq3-0004BL-Vk for ips@ietf.org; Wed, 14 Sep 2005 11:06:20 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j8EF1Kij015456 for ; Wed, 14 Sep 2005 11:01:20 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j8EF1Kje015451; Wed, 14 Sep 2005 11:01:20 -0400 Received: from pkoning.equallogic.com ([172.16.1.181]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 11:01:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17192.15166.533226.848821@gargle.gargle.HOWL> Date: Wed, 14 Sep 2005 11:01:18 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Subject: Re: [Ips] task aborts, r2t, and the F bit References: <17191.14934.386438.244953@gargle.gargle.HOWL> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 14 Sep 2005 15:01:20.0000 (UTC) FILETIME=[2A13A000:01C5B93D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Julian" == Julian Satran writes: Julian> Paul, The rule about the R2T was meant for the case the Julian> target issued some R2Ts before receiving or acting on abort. Julian> In this case a target may want to have all its R2T accounted Julian> for before it finishes the abort. Julian> The data have to be all there if the initiator can't Julian> ascertain that the data will be received after the abort is Julian> initiated. Julian> I assumed that when the initiator can be certain the data Julian> will be seen after the abort (e.g., they come on the same Julian> connection) it may ignore the "completeness" rule. It should Julian> also be possible to ignore the rule unilaterally (at the Julian> initiator) but then the "SCSI" part of the initiator should Julian> be prepared to act on errors resulting from this behavior. Thanks, that makes sense. There seems to be a difference in the spec when it talks about Abort Task Set vs. Abort Task. For the former, it explicitly requires that all pending R2Ts must be answered. For Abort Task, it doesn't say that, at least not explicitly. We're seeing an situation where we send R2T, the initiator answers with a couple of the Data Out PDUs but not the complete set, and then instead it sends Abort Task, and does NOT complete the R2T response. So it seems that we have to get rid of the task when we receive the abort, and assume that the rest of the DataOut burst will NOT arrive. (But then if it does arrive because some different initiator does complete the burst even after sending an Abort Task, we end up complaining about DataOut for a TTT we no longer know...) paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Sep 14 12:37:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFaGU-0008Bs-9Z; Wed, 14 Sep 2005 12:37:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFaGS-0008AK-7l for ips@megatron.ietf.org; Wed, 14 Sep 2005 12:37:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20349 for ; Wed, 14 Sep 2005 12:37:37 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFaL5-0006pJ-AQ for ips@ietf.org; Wed, 14 Sep 2005 12:42:28 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8EGbUd7185234 for ; Wed, 14 Sep 2005 16:37:30 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8EGbT16146818 for ; Wed, 14 Sep 2005 18:37:29 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8EGbTrO031402 for ; Wed, 14 Sep 2005 18:37:29 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8EGbTMM031399; Wed, 14 Sep 2005 18:37:29 +0200 In-Reply-To: <17192.15166.533226.848821@gargle.gargle.HOWL> To: Paul Koning Subject: Re: [Ips] task aborts, r2t, and the F bit MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Wed, 14 Sep 2005 19:37:26 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 14/09/2005 19:37:28, Serialize complete at 14/09/2005 19:37:28 X-Spam-Score: 0.5 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1304397226==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1304397226== Content-Type: multipart/alternative; boundary="=_alternative 0055A8C6C225707C_=" This is a multipart message in MIME format. --=_alternative 0055A8C6C225707C_= Content-Type: text/plain; charset="US-ASCII" Abort task MUST be issued on the same connection as the aborted command. The R2T requirement becomes useless (you won't send data after the abort). Julo Paul Koning 14-09-05 18:01 To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org Subject Re: [Ips] task aborts, r2t, and the F bit >>>>> "Julian" == Julian Satran writes: Julian> Paul, The rule about the R2T was meant for the case the Julian> target issued some R2Ts before receiving or acting on abort. Julian> In this case a target may want to have all its R2T accounted Julian> for before it finishes the abort. Julian> The data have to be all there if the initiator can't Julian> ascertain that the data will be received after the abort is Julian> initiated. Julian> I assumed that when the initiator can be certain the data Julian> will be seen after the abort (e.g., they come on the same Julian> connection) it may ignore the "completeness" rule. It should Julian> also be possible to ignore the rule unilaterally (at the Julian> initiator) but then the "SCSI" part of the initiator should Julian> be prepared to act on errors resulting from this behavior. Thanks, that makes sense. There seems to be a difference in the spec when it talks about Abort Task Set vs. Abort Task. For the former, it explicitly requires that all pending R2Ts must be answered. For Abort Task, it doesn't say that, at least not explicitly. We're seeing an situation where we send R2T, the initiator answers with a couple of the Data Out PDUs but not the complete set, and then instead it sends Abort Task, and does NOT complete the R2T response. So it seems that we have to get rid of the task when we receive the abort, and assume that the rest of the DataOut burst will NOT arrive. (But then if it does arrive because some different initiator does complete the burst even after sending an Abort Task, we end up complaining about DataOut for a TTT we no longer know...) paul --=_alternative 0055A8C6C225707C_= Content-Type: text/html; charset="US-ASCII"
Abort task MUST be issued on the same connection as the aborted command.
The R2T requirement becomes useless (you won't send data after the abort).

Julo


Paul Koning <pkoning@equallogic.com>

14-09-05 18:01

To
Julian Satran/Haifa/IBM@IBMIL
cc
ips@ietf.org
Subject
Re: [Ips] task aborts, r2t, and the F bit





>>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:

Julian> Paul, The rule about the R2T was meant for the case the
Julian> target issued some R2Ts before receiving or acting on abort.
Julian> In this case a target may want to have all its R2T accounted
Julian> for before it finishes the abort.

Julian> The data have to be all there if the initiator can't
Julian> ascertain that the data will be received after the abort is
Julian> initiated.

Julian> I assumed that when the initiator can be certain the data
Julian> will be seen after the abort (e.g., they come on the same
Julian> connection) it may ignore the "completeness" rule.  It should
Julian> also be possible to ignore the rule unilaterally (at the
Julian> initiator) but then the "SCSI" part of the initiator should
Julian> be prepared to act on errors resulting from this behavior.

Thanks, that makes sense.

There seems to be a difference in the spec when it talks about Abort
Task Set vs. Abort Task.  For the former, it explicitly requires that
all pending R2Ts must be answered.

For Abort Task, it doesn't say that, at least not explicitly.  We're
seeing an situation where we send R2T, the initiator answers with a
couple of the Data Out PDUs but not the complete set, and then instead
it sends Abort Task, and does NOT complete the R2T response.

So it seems that we have to get rid of the task when we receive the
abort, and assume that the rest of the DataOut burst will NOT arrive.
(But then if it does arrive because some different initiator does
complete the burst even after sending an Abort Task, we end up
complaining about DataOut for a TTT we no longer know...)

                    paul
--=_alternative 0055A8C6C225707C_=-- --===============1304397226== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1304397226==-- From ips-bounces@ietf.org Wed Sep 14 12:57:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFaZp-0004kz-HX; Wed, 14 Sep 2005 12:57:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFaZo-0004kp-D1 for ips@megatron.ietf.org; Wed, 14 Sep 2005 12:57:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21363 for ; Wed, 14 Sep 2005 12:57:37 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFaeQ-0007Ow-UM for ips@ietf.org; Wed, 14 Sep 2005 13:02:28 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j8EGvUij025569 for ; Wed, 14 Sep 2005 12:57:30 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j8EGvUje025564; Wed, 14 Sep 2005 12:57:30 -0400 Received: from pkoning.equallogic.com ([172.16.1.181]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Sep 2005 12:57:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17192.22136.643551.956850@gargle.gargle.HOWL> Date: Wed, 14 Sep 2005 12:57:28 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Subject: Re: [Ips] task aborts, r2t, and the F bit References: <17192.15166.533226.848821@gargle.gargle.HOWL> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 14 Sep 2005 16:57:29.0936 (UTC) FILETIME=[647B7500:01C5B94D] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Julian" == Julian Satran writes: Julian> Abort task MUST be issued on the same connection as the Julian> aborted command. The R2T requirement becomes useless (you Julian> won't send data after the abort). That assumes that the part of the initiator that issues Abort Task is synchronized with the fastpath machinery that answers R2T. Is that required? And yes, I agree that (if there is that synchronization) then answering R2T after the Abort Task is not useful. Does the spec explicitly say that you MUST NOT send any more Data Out after an Abort Task? I couldn't find that. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 15 03:44:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFoQ5-00064r-6F; Thu, 15 Sep 2005 03:44:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFoQ3-00064i-63 for ips@megatron.ietf.org; Thu, 15 Sep 2005 03:44:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24638 for ; Thu, 15 Sep 2005 03:44:26 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFoUl-0007wj-2d for ips@ietf.org; Thu, 15 Sep 2005 03:49:24 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8F7iHd7191294 for ; Thu, 15 Sep 2005 07:44:17 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8F7iHhP179838 for ; Thu, 15 Sep 2005 09:44:17 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8F7iHpw016728 for ; Thu, 15 Sep 2005 09:44:17 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8F7iHFt016722; Thu, 15 Sep 2005 09:44:17 +0200 In-Reply-To: <17192.22136.643551.956850@gargle.gargle.HOWL> To: Paul Koning Subject: Re: [Ips] task aborts, r2t, and the F bit MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Thu, 15 Sep 2005 10:44:16 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 15/09/2005 10:44:16, Serialize complete at 15/09/2005 10:44:16 X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0269223371==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0269223371== Content-Type: multipart/alternative; boundary="=_alternative 0028C80AC225707D_=" This is a multipart message in MIME format. --=_alternative 0028C80AC225707D_= Content-Type: text/plain; charset="US-ASCII" Paul, The text does not say that you must not send Data Out after receiving abort. However the text does not mandate them either. I was trying to explain why responding to R2T is mandated for abort task set and it is not mandated for abort task (but not forbidden either). Julo Paul Koning 14-09-05 19:57 To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org Subject Re: [Ips] task aborts, r2t, and the F bit >>>>> "Julian" == Julian Satran writes: Julian> Abort task MUST be issued on the same connection as the Julian> aborted command. The R2T requirement becomes useless (you Julian> won't send data after the abort). That assumes that the part of the initiator that issues Abort Task is synchronized with the fastpath machinery that answers R2T. Is that required? And yes, I agree that (if there is that synchronization) then answering R2T after the Abort Task is not useful. Does the spec explicitly say that you MUST NOT send any more Data Out after an Abort Task? I couldn't find that. paul --=_alternative 0028C80AC225707D_= Content-Type: text/html; charset="US-ASCII"
Paul,

The text does not say that you must not send Data Out after receiving abort.
However the text does not mandate them either. I was trying to explain why responding to R2T is mandated for abort task set and it is not mandated for abort task (but not forbidden either).

Julo


Paul Koning <pkoning@equallogic.com>

14-09-05 19:57

To
Julian Satran/Haifa/IBM@IBMIL
cc
ips@ietf.org
Subject
Re: [Ips] task aborts, r2t, and the F bit





>>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:

Julian> Abort task MUST be issued on the same connection as the
Julian> aborted command.  The R2T requirement becomes useless (you
Julian> won't send data after the abort).

That assumes that the part of the initiator that issues Abort Task is
synchronized with the fastpath machinery that answers R2T.  Is that
required?

And yes, I agree that (if there is that synchronization) then
answering R2T after the Abort Task is not useful.  Does the spec
explicitly say that you MUST NOT send any more Data Out after an Abort
Task?  I couldn't find that.  

      paul
--=_alternative 0028C80AC225707D_=-- --===============0269223371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0269223371==-- From ips-bounces@ietf.org Thu Sep 15 05:54:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFqRc-0005eW-S5; Thu, 15 Sep 2005 05:54:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFqRa-0005eR-SC for ips@megatron.ietf.org; Thu, 15 Sep 2005 05:54:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00437 for ; Thu, 15 Sep 2005 05:54:11 -0400 (EDT) Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFqWL-0003JA-VL for ips@ietf.org; Thu, 15 Sep 2005 05:59:11 -0400 Received: from [192.168.7.172] (helo=winminx) by hammer with esmtp (Exim 4.12) id 1EFqOG-00019l-00; Thu, 15 Sep 2005 10:50:48 +0100 From: "Ken Sandars" To: "'William Studenmund'" , "'Mallikarjun C.'" Subject: RE: [Ips] Discovery text Date: Thu, 15 Sep 2005 10:53:09 +0100 Message-ID: <002001c5b9db$5c6163f0$ac07a8c0@elipsan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <145951d1fd1b4322ad98fbdc9d05ed96@wasabisystems.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: 'IPS' X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Mallikarjun, Great work on the rewrite of this text. Due to technical difficulties I never saw the original post, so I'm glad Bill replied! I agree with Bill's tweak, too. Cheers, Ken > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of William Studenmund > Sent: 12 September 2005 01:50 > To: Mallikarjun C. > Cc: IPS > Subject: Re: [Ips] Discovery text > > > On Sep 9, 2005, at 5:22 PM, Mallikarjun C. wrote: > > > The new proposed text is attached below. > > I have a minor comment (below), but overall, LOOKS GREAT! > > > I intend to shortly publish a -01 revision with several updates, > > including this one subject to agreement (which I hope > exists based on > > the threads so far....). > > > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > StorageWorks Division > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > cbm [at] rose.hp.com > > > > > > 5 Discovery semantics > > 5.1 Error Recovery for Discovery Sessions > > The negotiation of the key ErrorRecoveryLevel is irrelevant for > > Discovery sessions - i.e. for sessions that negotiated > > "SessionType=Discovery". The operational ErrorRecoveryLevel for > > Discovery sessions MUST be 0. This naturally follows from the > > functionality constraints [RFC3720] imposes on Discovery sessions. > > > > 5.2 Discovery Philosophy and Reinstatement > > Discovery sessions are intended to be relatively short-lived. > > Initiators are not expected to establish multiple Discovery > sessions > > to the same iSCSI Portal (see [RFC3720]). An initiator may use the > > same iSCSI Initiator Name and ISID when establishing > different unique > > sessions with different targets and/or different portal > groups. This > > behavior is discussed in Section 9.1.1 of [RFC3720] and is, > in fact, > > encouraged as conservative reuse of ISIDs. ISID RULE in [RFC3720] > > states that there must not be more than one session with a matching > > 4-tuple: . > > While the spirit of the ISID RULE applies to Discovery sessions the > > same as it does for Normal sessions, note that some > Discovery sessions > > differ from the Normal sessions in two important aspects: > > * Because [RFC3720] allows a Discovery session to be established > > without specifying a TargetName key in the Login Request > PDU (let us > > call such a session an "Unnamed" Discovery session), there is no > > Target Node context to enforce the ISID RULE. > > * Portal Groups are defined only in the context of a > Target Node. > > When the TargetName key is NULL-valued (i.e. not specified), the > > TargetPortalGroupTag thus cannot be ascertained to enforce the ISID > > RULE. > > > > The following sections describe the two scenarios - Named Discovery > > sessions and Unnamed Discovery sessions - separately. > > > > 5.2.1 Unnamed Discovery Sessions > > For Unnamed Discovery sessions, neither the TargetName nor the > > TargetPortalGroupTag is available to the targets in order > to enforce > > the ISID RULE. So the following rule applies. > > > > UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the > > following 4-tuple for Unnamed Discovery sessions: > ISID, NULL, TargetAddress>. The following semantics are implied by > > this uniqueness requirement. > > > > Resources permitting, targets MUST allow concurrent > establishment of > > one Discovery session with each of its > > I'm not sure if we're supposed to use "MUST" like this. I think > "SHOULD" is the correct word; we definitely think the target must do > this, but realize there may be an occasion in which it can't. > > > Portals by the same initiator port with a given iSCSI Node > Name and an > > ISID. Each of the concurrent Discovery sessions, if established by > > the same initiator port, MUST be treated as independent sessions - > > i.e. one session MUST NOT reinstate the other. > > > > A new Unnamed Discovery session that has a matching > ISID, NULL, TargetAddress> to an existing discovery session MUST > > reinstate the existing Unnamed Discovery session. Note > thus that only > > an Unnamed Discovery session may reinstate an Unnamed Discovery > > session. > > > > 5.2.2 Named Discovery Sessions > > For a Named Discovery session, the TargetName key is > specified by the > > initiator and thus the target can unambiguously ascertain the > > TargetPortalGroupTag as well. Since all the four elements of the > > 4-tuple are known, the ISID RULE MUST be enforced by > targets with no > > changes from [RFC3720] semantics. A new session with a matching > > thus will > > reinstate an existing session. Note in this case that any > new iSCSI > > session (Discovery or Normal) with the matching 4-tuple may > reinstate > > an existing Named Discovery iSCSI session. > > Take care, > > Bill > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 15 09:11:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtWa-00008Z-1n; Thu, 15 Sep 2005 09:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtWW-00008M-TY for ips@megatron.ietf.org; Thu, 15 Sep 2005 09:11:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09318 for ; Thu, 15 Sep 2005 09:11:30 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFtbL-0000Gs-69 for ips@ietf.org; Thu, 15 Sep 2005 09:16:31 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j8FDBLij003404 for ; Thu, 15 Sep 2005 09:11:21 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j8FDBLje003399; Thu, 15 Sep 2005 09:11:21 -0400 Received: from pkoning.equallogic.com ([172.16.1.181]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Sep 2005 09:11:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17193.29431.50206.286758@gargle.gargle.HOWL> Date: Thu, 15 Sep 2005 09:11:19 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Subject: Re: [Ips] task aborts, r2t, and the F bit References: <17192.22136.643551.956850@gargle.gargle.HOWL> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 15 Sep 2005 13:11:21.0076 (UTC) FILETIME=[F7397B40:01C5B9F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Julian" == Julian Satran writes: Julian> Paul, The text does not say that you must not send Data Out Julian> after receiving abort. However the text does not mandate Julian> them either. I was trying to explain why responding to R2T is Julian> mandated for abort task set and it is not mandated for abort Julian> task (but not forbidden either). Ok, thanks. That lack of detail doesn't help implementers. The spec really should discuss this explicitly. Mallikarjun, perhaps something for your document? The conclusion I come to is that targets MUST assume that there will be no more Data Out PDUs after an Abort Target. If any do arrive, they can handle them in the usual way. Initiators that continue to send Data Out after sending an Abort Task must be prepared to see those PDUs rejected by the target. Right? paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 15 09:22:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtgy-00040h-8c; Thu, 15 Sep 2005 09:22:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtgw-00040T-8f for ips@megatron.ietf.org; Thu, 15 Sep 2005 09:22:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09874 for ; Thu, 15 Sep 2005 09:22:16 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFtlj-0000cV-Gy for ips@ietf.org; Thu, 15 Sep 2005 09:27:16 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc14) with SMTP id <200509151322040140023kace>; Thu, 15 Sep 2005 13:22:05 +0000 Message-ID: <003c01c5b9f8$7714d890$0a031eac@ivivity.com> From: "Eddy Quicksall" To: "'Mallikarjun C.'" References: <002001c5b9db$5c6163f0$ac07a8c0@elipsan.com> Subject: Re: [Ips] Discovery text Date: Thu, 15 Sep 2005 09:21:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit Cc: 'IPS' X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org It would seem to me that since there may be a requirement to change existing code to comply with this you should increase the version number. Eddy ----- Original Message ----- From: "Ken Sandars" To: "'William Studenmund'" ; "'Mallikarjun C.'" Cc: "'IPS'" Sent: Thursday, September 15, 2005 5:53 AM Subject: RE: [Ips] Discovery text > Hi Mallikarjun, > > Great work on the rewrite of this text. Due to technical difficulties I > never saw the original post, so I'm glad Bill replied! I agree with Bill's > tweak, too. > > Cheers, > Ken > >> -----Original Message----- >> From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On >> Behalf Of William Studenmund >> Sent: 12 September 2005 01:50 >> To: Mallikarjun C. >> Cc: IPS >> Subject: Re: [Ips] Discovery text >> >> >> On Sep 9, 2005, at 5:22 PM, Mallikarjun C. wrote: >> >> > The new proposed text is attached below. >> >> I have a minor comment (below), but overall, LOOKS GREAT! >> >> > I intend to shortly publish a -01 revision with several updates, >> > including this one subject to agreement (which I hope >> exists based on >> > the threads so far....). >> > >> > Mallikarjun >> > >> > Mallikarjun Chadalapaka >> > Networked Storage Architecture >> > StorageWorks Division >> > Hewlett-Packard MS 5668 >> > Roseville CA 95747 >> > cbm [at] rose.hp.com >> > >> > >> > 5 Discovery semantics >> > 5.1 Error Recovery for Discovery Sessions >> > The negotiation of the key ErrorRecoveryLevel is irrelevant for >> > Discovery sessions - i.e. for sessions that negotiated >> > "SessionType=Discovery". The operational ErrorRecoveryLevel for >> > Discovery sessions MUST be 0. This naturally follows from the >> > functionality constraints [RFC3720] imposes on Discovery sessions. >> > >> > 5.2 Discovery Philosophy and Reinstatement >> > Discovery sessions are intended to be relatively short-lived. >> > Initiators are not expected to establish multiple Discovery >> sessions >> > to the same iSCSI Portal (see [RFC3720]). An initiator may use the >> > same iSCSI Initiator Name and ISID when establishing >> different unique >> > sessions with different targets and/or different portal >> groups. This >> > behavior is discussed in Section 9.1.1 of [RFC3720] and is, >> in fact, >> > encouraged as conservative reuse of ISIDs. ISID RULE in [RFC3720] >> > states that there must not be more than one session with a matching >> > 4-tuple: . >> > While the spirit of the ISID RULE applies to Discovery sessions the >> > same as it does for Normal sessions, note that some >> Discovery sessions >> > differ from the Normal sessions in two important aspects: >> > * Because [RFC3720] allows a Discovery session to be established >> > without specifying a TargetName key in the Login Request >> PDU (let us >> > call such a session an "Unnamed" Discovery session), there is no >> > Target Node context to enforce the ISID RULE. >> > * Portal Groups are defined only in the context of a >> Target Node. >> > When the TargetName key is NULL-valued (i.e. not specified), the >> > TargetPortalGroupTag thus cannot be ascertained to enforce the ISID >> > RULE. >> > >> > The following sections describe the two scenarios - Named Discovery >> > sessions and Unnamed Discovery sessions - separately. >> > >> > 5.2.1 Unnamed Discovery Sessions >> > For Unnamed Discovery sessions, neither the TargetName nor the >> > TargetPortalGroupTag is available to the targets in order >> to enforce >> > the ISID RULE. So the following rule applies. >> > >> > UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the >> > following 4-tuple for Unnamed Discovery sessions: > > ISID, NULL, TargetAddress>. The following semantics are implied by >> > this uniqueness requirement. >> > >> > Resources permitting, targets MUST allow concurrent >> establishment of >> > one Discovery session with each of its >> >> I'm not sure if we're supposed to use "MUST" like this. I think >> "SHOULD" is the correct word; we definitely think the target must do >> this, but realize there may be an occasion in which it can't. >> >> > Portals by the same initiator port with a given iSCSI Node >> Name and an >> > ISID. Each of the concurrent Discovery sessions, if established by >> > the same initiator port, MUST be treated as independent sessions - >> > i.e. one session MUST NOT reinstate the other. >> > >> > A new Unnamed Discovery session that has a matching > > ISID, NULL, TargetAddress> to an existing discovery session MUST >> > reinstate the existing Unnamed Discovery session. Note >> thus that only >> > an Unnamed Discovery session may reinstate an Unnamed Discovery >> > session. >> > >> > 5.2.2 Named Discovery Sessions >> > For a Named Discovery session, the TargetName key is >> specified by the >> > initiator and thus the target can unambiguously ascertain the >> > TargetPortalGroupTag as well. Since all the four elements of the >> > 4-tuple are known, the ISID RULE MUST be enforced by >> targets with no >> > changes from [RFC3720] semantics. A new session with a matching >> > thus will >> > reinstate an existing session. Note in this case that any >> new iSCSI >> > session (Discovery or Normal) with the matching 4-tuple may >> reinstate >> > an existing Named Discovery iSCSI session. >> >> Take care, >> >> Bill >> > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 15 09:27:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtld-0004xq-4t; Thu, 15 Sep 2005 09:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFtlc-0004xl-1K for ips@megatron.ietf.org; Thu, 15 Sep 2005 09:27:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10127 for ; Thu, 15 Sep 2005 09:27:05 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFtqQ-0000mC-Hg for ips@ietf.org; Thu, 15 Sep 2005 09:32:06 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc14) with SMTP id <200509151326580140022co5e>; Thu, 15 Sep 2005 13:26:58 +0000 Message-ID: <004301c5b9f9$26332b10$0a031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Thu, 15 Sep 2005 09:26:58 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Ips] DataSequenceInOrder for non-immediate unsolicited X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1608601124==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1608601124== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C5B9D7.9ECE13E0" This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C5B9D7.9ECE13E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 12.9 DataSequenceInOrder If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). Up to the paren, this seems to apply to even non-immediate unsolicited = but there is a slight implication here, by distinctly referencing the = R2T, that this may not apply to non-immediate unsolicited PDUs. What is = the correct interpretation? Eddy ------=_NextPart_000_0040_01C5B9D7.9ECE13E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
12.9 DataSequenceInOrder
 
   If DataSequenceInOrder is set to Yes, = Data=20 Sequences MUST be
   transferred using continuously = non-decreasing=20 sequence offsets (R2T
   buffer offset for writes, or the = smallest=20 SCSI Data-In buffer offset
   within a read data=20 sequence).
 
Up to the paren, this seems to apply to even = non-immediate=20 unsolicited but there is a slight implication here, by distinctly = referencing=20 the R2T, that this may not apply to non-immediate unsolicited PDUs. What = is the=20 correct interpretation?
 
Eddy
------=_NextPart_000_0040_01C5B9D7.9ECE13E0-- --===============1608601124== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1608601124==-- From ips-bounces@ietf.org Thu Sep 15 09:53:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFuBa-0004fe-Bm; Thu, 15 Sep 2005 09:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFuBY-0004eH-TN for ips@megatron.ietf.org; Thu, 15 Sep 2005 09:53:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11392 for ; Thu, 15 Sep 2005 09:53:54 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFuGL-0001WX-C5 for ips@ietf.org; Thu, 15 Sep 2005 09:58:55 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8FDrFOI123322 for ; Thu, 15 Sep 2005 13:53:23 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8FDrFhP180898 for ; Thu, 15 Sep 2005 15:53:15 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8FDrFnt018390 for ; Thu, 15 Sep 2005 15:53:15 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8FDrFMX018385; Thu, 15 Sep 2005 15:53:15 +0200 In-Reply-To: <17193.29431.50206.286758@gargle.gargle.HOWL> To: Paul Koning Subject: Re: [Ips] task aborts, r2t, and the F bit MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Thu, 15 Sep 2005 16:53:12 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 15/09/2005 16:53:14, Serialize complete at 15/09/2005 16:53:14 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1461909700==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1461909700== Content-Type: multipart/alternative; boundary="=_alternative 004A868AC225707D_=" This is a multipart message in MIME format. --=_alternative 004A868AC225707D_= Content-Type: text/plain; charset="US-ASCII" Paul Koning wrote on 15-09-2005 16:11:19: > >>>>> "Julian" == Julian Satran writes: > > Julian> Paul, The text does not say that you must not send Data Out > Julian> after receiving abort. However the text does not mandate > Julian> them either. I was trying to explain why responding to R2T is > Julian> mandated for abort task set and it is not mandated for abort > Julian> task (but not forbidden either). > > Ok, thanks. > > That lack of detail doesn't help implementers. The spec really should > discuss this explicitly. Mallikarjun, perhaps something for your > document? > Text has to express clearly the intended spec and like any spec will say it with as few words as possible. Adding words just increases the probability of errors. I don't see it as lacking detail but it certainly lacks redundancy. > The conclusion I come to is that targets MUST assume that there will > be no more Data Out PDUs after an Abort Target. If any do arrive, I assume you meant Abort task. Yes targets are right to assume no more data-out after abort task. > they can handle them in the usual way. Initiators that continue to > send Data Out after sending an Abort Task must be prepared to see > those PDUs rejected by the target. > > Right? Yes. > > paul > --=_alternative 004A868AC225707D_= Content-Type: text/html; charset="US-ASCII"

Paul Koning <pkoning@equallogic.com> wrote on 15-09-2005 16:11:19:

> >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:
>
>  Julian> Paul, The text does not say that you must not send Data Out
>  Julian> after receiving abort.  However the text does not mandate
>  Julian> them either. I was trying to explain why responding to R2T is
>  Julian> mandated for abort task set and it is not mandated for abort
>  Julian> task (but not forbidden either).
>
> Ok, thanks.
>
> That lack of detail doesn't help implementers.  The spec really should
> discuss this explicitly.  Mallikarjun, perhaps something for your
> document?
>

Text has to express clearly the intended spec and like any spec will say it with as few words as possible.
Adding words just increases the probability of errors.
I don't see it as lacking detail but it certainly lacks redundancy.

> The conclusion I come to is that targets MUST assume that there will
> be no more Data Out PDUs after an Abort Target.  If any do arrive,

I assume you meant Abort task. Yes targets are right to assume no more data-out after abort task.

> they can handle them in the usual way.  Initiators that continue to
> send Data Out after sending an Abort Task must be prepared to see
> those PDUs rejected by the target.
>
> Right?

Yes.

>
>    paul
>
--=_alternative 004A868AC225707D_=-- --===============1461909700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1461909700==-- From ips-bounces@ietf.org Thu Sep 15 12:08:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFwI0-0000R8-6E; Thu, 15 Sep 2005 12:08:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFwHn-0000PX-Ad for ips@megatron.ietf.org; Thu, 15 Sep 2005 12:08:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19467 for ; Thu, 15 Sep 2005 12:08:28 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFwMZ-00058n-8q for ips@ietf.org; Thu, 15 Sep 2005 12:13:31 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 7D40F8706C; Thu, 15 Sep 2005 12:08:09 -0400 (EDT) In-Reply-To: <003c01c5b9f8$7714d890$0a031eac@ivivity.com> References: <002001c5b9db$5c6163f0$ac07a8c0@elipsan.com> <003c01c5b9f8$7714d890$0a031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <2affbda8ff2ab5e1371cf2cf9d353c7c@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery text Date: Thu, 15 Sep 2005 09:08:01 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 'IPS' , "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1307416981==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1307416981== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-316910172" Content-Transfer-Encoding: 7bit --Apple-Mail-1-316910172 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 15, 2005, at 6:21 AM, Eddy Quicksall wrote: > It would seem to me that since there may be a requirement to change > existing code to comply with this you should increase the version > number. I don't think we need to go that far. Since we are addressing issues that came up in RFC 3720, we are encountering things that didn't work out right the first time around. So fixing them is not necessarily a new version of the protocol; things were "broken" before, so the changes aren't breaking anything and thus won't trigger interoperation issues. Thus we don't need a new version number. Take care, Bill --Apple-Mail-1-316910172 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDKZxnDJT2Egh26K0RAk8FAJ91QL7jPf4UsZDi7q6mv7Vumx3kvgCePnz4 JPVFKsHHkWXTTL5fkaDmTME= =Vc41 -----END PGP SIGNATURE----- --Apple-Mail-1-316910172-- --===============1307416981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1307416981==-- From ips-bounces@ietf.org Thu Sep 15 12:37:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFwje-0001Kf-6F; Thu, 15 Sep 2005 12:37:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFwjb-0001Ka-PP for ips@megatron.ietf.org; Thu, 15 Sep 2005 12:37:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20775 for ; Thu, 15 Sep 2005 12:37:12 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFwoO-0005uE-Of for ips@ietf.org; Thu, 15 Sep 2005 12:42:16 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc11) with SMTP id <2005091516370201100pe6bae>; Thu, 15 Sep 2005 16:37:02 +0000 Message-ID: <006001c5ba13$b3974f30$0a031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <002001c5b9db$5c6163f0$ac07a8c0@elipsan.com> <003c01c5b9f8$7714d890$0a031eac@ivivity.com> <2affbda8ff2ab5e1371cf2cf9d353c7c@wasabisystems.com> Subject: Re: [Ips] Discovery text Date: Thu, 15 Sep 2005 12:37:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: 'IPS' , "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org My problem is with the word MUST. Since the RFC did not require this behavior then some people may have already coded it not in accordance with the MUST case. If changed to a SHOULD as you pointed out earlier, I don't have a problem. Actually I think it should be MAY because some people think SHOULD means MUST. > > Resources permitting, targets MUST allow concurrent > establishment of > > one Discovery session with each of its > > I'm not sure if we're supposed to use "MUST" like this. I think > "SHOULD" is the correct word; we definitely think the target must do > this, but realize there may be an occasion in which it can't. > > > Portals by the same initiator port with a given iSCSI Node > Name and an > > ISID. Eddy ----- Original Message ----- From: "William Studenmund" To: "Eddy Quicksall" Cc: "'Mallikarjun C.'" ; "'IPS'" Sent: Thursday, September 15, 2005 12:08 PM Subject: Re: [Ips] Discovery text On Sep 15, 2005, at 6:21 AM, Eddy Quicksall wrote: > It would seem to me that since there may be a requirement to change > existing code to comply with this you should increase the version > number. I don't think we need to go that far. Since we are addressing issues that came up in RFC 3720, we are encountering things that didn't work out right the first time around. So fixing them is not necessarily a new version of the protocol; things were "broken" before, so the changes aren't breaking anything and thus won't trigger interoperation issues. Thus we don't need a new version number. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 15 12:53:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFwzZ-0005rP-O9; Thu, 15 Sep 2005 12:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFwzX-0005nf-6V for ips@megatron.ietf.org; Thu, 15 Sep 2005 12:53:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21385 for ; Thu, 15 Sep 2005 12:53:39 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFx4M-0006JQ-Fo for ips@ietf.org; Thu, 15 Sep 2005 12:58:43 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id E9F588708B; Thu, 15 Sep 2005 12:53:39 -0400 (EDT) In-Reply-To: <006001c5ba13$b3974f30$0a031eac@ivivity.com> References: <002001c5b9db$5c6163f0$ac07a8c0@elipsan.com> <003c01c5b9f8$7714d890$0a031eac@ivivity.com> <2affbda8ff2ab5e1371cf2cf9d353c7c@wasabisystems.com> <006001c5ba13$b3974f30$0a031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <7119566015aa1ffed6145321f54729f0@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery text Date: Thu, 15 Sep 2005 09:53:31 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: 'IPS' , "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0481582908==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0481582908== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-319640169" Content-Transfer-Encoding: 7bit --Apple-Mail-2-319640169 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 15, 2005, at 9:37 AM, Eddy Quicksall wrote: > My problem is with the word MUST. Since the RFC did not require this > behavior then some people may have already coded it not in accordance > with the MUST case. If changed to a SHOULD as you pointed out earlier, > I don't have a problem. Actually I think it should be MAY because some > people think SHOULD means MUST. Well, they need to read the spec, specifically the reference to what SHOULD, MUST, and MAY mean. SHOULD is a MUST you can weasel out of. :-) I agree that code that was fine before now isn't. I however do not think that means that we need a version change. Specifically, I assume you mean the iSCSI protocol version, since it's the only version number we have around. The document we are working on will eventually become an RFC. What I expect will happen is that products will start claiming to support RFC 3720 and also whatever RFC this one is (or it could be "RFC 3720 as updated in RFC foo"). Take care, Bill > > Resources permitting, targets MUST allow concurrent >> establishment of >> > one Discovery session with each of its >> >> I'm not sure if we're supposed to use "MUST" like this. I think >> "SHOULD" is the correct word; we definitely think the target must do >> this, but realize there may be an occasion in which it can't. >> >> > Portals by the same initiator port with a given iSCSI Node >> Name and an >> > ISID. > > Eddy > ----- Original Message ----- From: "William Studenmund" > > To: "Eddy Quicksall" > Cc: "'Mallikarjun C.'" ; "'IPS'" > Sent: Thursday, September 15, 2005 12:08 PM > Subject: Re: [Ips] Discovery text > On Sep 15, 2005, at 6:21 AM, Eddy Quicksall wrote: > >> It would seem to me that since there may be a requirement to change >> existing code to comply with this you should increase the version >> number. > > I don't think we need to go that far. Since we are addressing issues > that came up in RFC 3720, we are encountering things that didn't work > out right the first time around. So fixing them is not necessarily a > new version of the protocol; things were "broken" before, so the > changes aren't breaking anything and thus won't trigger interoperation > issues. Thus we don't need a new version number. > > Take care, > > Bill > > > > --Apple-Mail-2-319640169 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDKacQDJT2Egh26K0RAh5IAKCJKAMfzSUG74fJ+HLTNSvtiwp+cQCeI0VT jFr7VW8XkB+BfLZwtAYTM+s= =Ssp4 -----END PGP SIGNATURE----- --Apple-Mail-2-319640169-- --===============0481582908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0481582908==-- From ips-bounces@ietf.org Thu Sep 15 13:19:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxOu-0002rJ-6i; Thu, 15 Sep 2005 13:19:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxOs-0002r4-LQ for ips@megatron.ietf.org; Thu, 15 Sep 2005 13:19:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22264 for ; Thu, 15 Sep 2005 13:19:51 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFxTg-0006uq-I4 for ips@ietf.org; Thu, 15 Sep 2005 13:24:55 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc14) with SMTP id <2005091517193801400jqaahe>; Thu, 15 Sep 2005 17:19:38 +0000 Message-ID: <007e01c5ba19$a7395bb0$0a031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <002001c5b9db$5c6163f0$ac07a8c0@elipsan.com> <003c01c5b9f8$7714d890$0a031eac@ivivity.com> <2affbda8ff2ab5e1371cf2cf9d353c7c@wasabisystems.com> <006001c5ba13$b3974f30$0a031eac@ivivity.com> <7119566015aa1ffed6145321f54729f0@wasabisystems.com> Subject: Re: [Ips] Discovery text Date: Thu, 15 Sep 2005 13:19:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: 'IPS' , "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Then SHOULD is better than MUST. Eddy ----- Original Message ----- From: "William Studenmund" To: "Eddy Quicksall" Cc: "'Mallikarjun C.'" ; "'IPS'" Sent: Thursday, September 15, 2005 12:53 PM Subject: Re: [Ips] Discovery text On Sep 15, 2005, at 9:37 AM, Eddy Quicksall wrote: > My problem is with the word MUST. Since the RFC did not require this > behavior then some people may have already coded it not in accordance > with the MUST case. If changed to a SHOULD as you pointed out earlier, > I don't have a problem. Actually I think it should be MAY because some > people think SHOULD means MUST. Well, they need to read the spec, specifically the reference to what SHOULD, MUST, and MAY mean. SHOULD is a MUST you can weasel out of. :-) I agree that code that was fine before now isn't. I however do not think that means that we need a version change. Specifically, I assume you mean the iSCSI protocol version, since it's the only version number we have around. The document we are working on will eventually become an RFC. What I expect will happen is that products will start claiming to support RFC 3720 and also whatever RFC this one is (or it could be "RFC 3720 as updated in RFC foo"). Take care, Bill > > Resources permitting, targets MUST allow concurrent >> establishment of >> > one Discovery session with each of its >> >> I'm not sure if we're supposed to use "MUST" like this. I think >> "SHOULD" is the correct word; we definitely think the target must do >> this, but realize there may be an occasion in which it can't. >> >> > Portals by the same initiator port with a given iSCSI Node >> Name and an >> > ISID. > > Eddy > ----- Original Message ----- From: "William Studenmund" > > To: "Eddy Quicksall" > Cc: "'Mallikarjun C.'" ; "'IPS'" > Sent: Thursday, September 15, 2005 12:08 PM > Subject: Re: [Ips] Discovery text > On Sep 15, 2005, at 6:21 AM, Eddy Quicksall wrote: > >> It would seem to me that since there may be a requirement to change >> existing code to comply with this you should increase the version >> number. > > I don't think we need to go that far. Since we are addressing issues > that came up in RFC 3720, we are encountering things that didn't work > out right the first time around. So fixing them is not necessarily a > new version of the protocol; things were "broken" before, so the > changes aren't breaking anything and thus won't trigger interoperation > issues. Thus we don't need a new version number. > > Take care, > > Bill > > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 15 13:23:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxSE-00048k-Fj; Thu, 15 Sep 2005 13:23:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxSC-00048c-9h for ips@megatron.ietf.org; Thu, 15 Sep 2005 13:23:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22459 for ; Thu, 15 Sep 2005 13:23:16 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFxX1-00071U-Db for ips@ietf.org; Thu, 15 Sep 2005 13:28:21 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc13) with SMTP id <2005091517230201300a6ij8e>; Thu, 15 Sep 2005 17:23:06 +0000 Message-ID: <008c01c5ba1a$2309ad80$0a031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <002001c5b9db$5c6163f0$ac07a8c0@elipsan.com> <003c01c5b9f8$7714d890$0a031eac@ivivity.com> <2affbda8ff2ab5e1371cf2cf9d353c7c@wasabisystems.com> <006001c5ba13$b3974f30$0a031eac@ivivity.com> <7119566015aa1ffed6145321f54729f0@wasabisystems.com> Subject: Re: [Ips] Discovery text Date: Thu, 15 Sep 2005 13:23:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: 'IPS' , "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >I agree that code that was fine before now isn't. I however do not >think that means that we need a version change. Specifically, I assume >you mean the iSCSI protocol version, since it's the only version number >we have around. > >The document we are working on will eventually become an RFC. What I >expect will happen is that products will start claiming to support RFC >3720 and also whatever RFC this one is (or it could be "RFC 3720 as >updated in RFC foo"). If the version number is not going to change then a statement saying that initiators MUST stay backward compatable to RFC3720. If you don't do that you will have interoperability problems. Eddy _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 15 13:40:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxiX-0000K9-UE; Thu, 15 Sep 2005 13:40:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxiV-0000K4-Op for ips@megatron.ietf.org; Thu, 15 Sep 2005 13:40:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23117 for ; Thu, 15 Sep 2005 13:40:10 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFxnK-0007QF-Vu for ips@ietf.org; Thu, 15 Sep 2005 13:45:12 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc11) with SMTP id <2005091517395501100panrte>; Thu, 15 Sep 2005 17:39:55 +0000 Message-ID: <009c01c5ba1c$7c83a4e0$0a031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" , "Mallikarjun C." References: <4209e5cc97cf74b05afedffc257cdff3@wasabisystems.com><431F149A.7060500@rose.hp.com> <43222746.5060309@rose.hp.com> <145951d1fd1b4322ad98fbdc9d05ed96@wasabisystems.com> Subject: Re: [Ips] Discovery text Date: Thu, 15 Sep 2005 13:39:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org So far in the RFC we have always used the word Portal with a clear statement as to if it is a Network Portal or a Portal Group. I would suggest that in the below sentence the word Portal Groups is used instead of just Portal: > Resources permitting, targets MUST allow concurrent establishment of > one Discovery session with each of its > Portals by the same initiator port with a given iSCSI Node Name and an > ISID. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 15 13:44:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxmj-0000xW-Dl; Thu, 15 Sep 2005 13:44:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxmh-0000xH-9I for ips@megatron.ietf.org; Thu, 15 Sep 2005 13:44:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23348 for ; Thu, 15 Sep 2005 13:44:29 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFxrW-0007Wv-0i for ips@ietf.org; Thu, 15 Sep 2005 13:49:32 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id C5F0087062; Thu, 15 Sep 2005 13:44:25 -0400 (EDT) In-Reply-To: <008c01c5ba1a$2309ad80$0a031eac@ivivity.com> References: <002001c5b9db$5c6163f0$ac07a8c0@elipsan.com> <003c01c5b9f8$7714d890$0a031eac@ivivity.com> <2affbda8ff2ab5e1371cf2cf9d353c7c@wasabisystems.com> <006001c5ba13$b3974f30$0a031eac@ivivity.com> <7119566015aa1ffed6145321f54729f0@wasabisystems.com> <008c01c5ba1a$2309ad80$0a031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <047b3a1eb4c989fb110916fa3256c908@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery text Date: Thu, 15 Sep 2005 10:44:19 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'IPS' , "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1444812747==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1444812747== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4-322688135" Content-Transfer-Encoding: 7bit --Apple-Mail-4-322688135 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 15, 2005, at 10:23 AM, Eddy Quicksall wrote: >> I agree that code that was fine before now isn't. I however do not >> think that means that we need a version change. Specifically, I assume >> you mean the iSCSI protocol version, since it's the only version >> number >> we have around. >> >> The document we are working on will eventually become an RFC. What I >> expect will happen is that products will start claiming to support RFC >> 3720 and also whatever RFC this one is (or it could be "RFC 3720 as >> updated in RFC foo"). > > If the version number is not going to change then a statement saying > that initiators MUST stay backward compatable to RFC3720. If you don't > do that you will have interoperability problems. How? We're talking about a part of the spec that didn't work right in RFC 3720. Why do we need to stick to it in a backwards-compatible way? I would agree with you (strongly) if I felt we were breaking a working behavior. But with respect to discovery, I don't think we are. The requirements on initiators are rather light; don't open multiple discovery sessions to the same portal. Take care, Bill --Apple-Mail-4-322688135 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDKbL4DJT2Egh26K0RAgo+AKCG177CHJRiJHrJZh8ckHcYYxVJBACdFlph iNcyzBrosQisjeULkXdBjmU= =txFQ -----END PGP SIGNATURE----- --Apple-Mail-4-322688135-- --===============1444812747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1444812747==-- From ips-bounces@ietf.org Thu Sep 15 13:50:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxsG-0003N4-Pm; Thu, 15 Sep 2005 13:50:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxsF-0003Mw-LM for ips@megatron.ietf.org; Thu, 15 Sep 2005 13:50:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23618 for ; Thu, 15 Sep 2005 13:50:14 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFxx5-0007h8-G8 for ips@ietf.org; Thu, 15 Sep 2005 13:55:16 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 43DB687062; Thu, 15 Sep 2005 13:50:13 -0400 (EDT) In-Reply-To: <009c01c5ba1c$7c83a4e0$0a031eac@ivivity.com> References: <4209e5cc97cf74b05afedffc257cdff3@wasabisystems.com><431F149A.7060500@rose.hp.com> <43222746.5060309@rose.hp.com> <145951d1fd1b4322ad98fbdc9d05ed96@wasabisystems.com> <009c01c5ba1c$7c83a4e0$0a031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] Discovery text Date: Thu, 15 Sep 2005 10:50:06 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: IPS , "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0937566902==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0937566902== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-323035001" Content-Transfer-Encoding: 7bit --Apple-Mail-5-323035001 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 15, 2005, at 10:39 AM, Eddy Quicksall wrote: > So far in the RFC we have always used the word Portal with a clear > statement as to if it is a Network Portal or a Portal Group. I would > suggest that in the below sentence the word Portal Groups is used > instead of just Portal: > >> Resources permitting, targets MUST allow concurrent establishment of >> one Discovery session with each of its >> Portals by the same initiator port with a given iSCSI Node Name and an >> ISID. I agree we may need a bit more clarification. However this paragraph is in section 5.2.1, which is the unnamed discovery session behavior. As such (and this was a big part of the earlier "great thread"), we do not have well-defined target portal groups, thus we can't use TPGT. I think a better change would be to use "Network Portal." Take care, Bill --Apple-Mail-5-323035001 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDKbRUDJT2Egh26K0RAiccAJ9dCzvF8I++ZTz1dMP2wXM5gtsgGgCbBNIo Q2hk3LEz762Ki23Te/q5+SQ= =U/LV -----END PGP SIGNATURE----- --Apple-Mail-5-323035001-- --===============0937566902== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0937566902==-- From ips-bounces@ietf.org Thu Sep 15 13:56:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxy3-0004xr-O2; Thu, 15 Sep 2005 13:56:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFxy1-0004we-SG for ips@megatron.ietf.org; Thu, 15 Sep 2005 13:56:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23863 for ; Thu, 15 Sep 2005 13:56:12 -0400 (EDT) Received: from sccrmhc13.comcast.net ([63.240.76.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFy2r-0007qc-NY for ips@ietf.org; Thu, 15 Sep 2005 14:01:14 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc13) with SMTP id <2005091517560201300aceile>; Thu, 15 Sep 2005 17:56:02 +0000 Message-ID: <00c401c5ba1e$bd42e430$0a031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <4209e5cc97cf74b05afedffc257cdff3@wasabisystems.com><431F149A.7060500@rose.hp.com><43222746.5060309@rose.hp.com><145951d1fd1b4322ad98fbdc9d05ed96@wasabisystems.com><009c01c5ba1c$7c83a4e0$0a031eac@ivivity.com> Subject: Re: [Ips] Discovery text Date: Thu, 15 Sep 2005 13:56:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: IPS , "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Thanks for the catch ... I actually meant to say Network Portal. Eddy ----- Original Message ----- From: "William Studenmund" To: "Eddy Quicksall" Cc: "IPS" ; "Mallikarjun C." Sent: Thursday, September 15, 2005 1:50 PM Subject: Re: [Ips] Discovery text > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > On Sep 15, 2005, at 10:39 AM, Eddy Quicksall wrote: > So far in the RFC we have always used the word Portal with a clear > statement as to if it is a Network Portal or a Portal Group. I would > suggest that in the below sentence the word Portal Groups is used > instead of just Portal: > >> Resources permitting, targets MUST allow concurrent establishment of >> one Discovery session with each of its >> Portals by the same initiator port with a given iSCSI Node Name and an >> ISID. I agree we may need a bit more clarification. However this paragraph is in section 5.2.1, which is the unnamed discovery session behavior. As such (and this was a big part of the earlier "great thread"), we do not have well-defined target portal groups, thus we can't use TPGT. I think a better change would be to use "Network Portal." Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 15 14:38:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFydG-0008C3-MZ; Thu, 15 Sep 2005 14:38:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFydE-0008Bn-KC for ips@megatron.ietf.org; Thu, 15 Sep 2005 14:38:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26973 for ; Thu, 15 Sep 2005 14:38:46 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFyi4-0000oq-In for ips@ietf.org; Thu, 15 Sep 2005 14:43:50 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8FIcUO0207022 for ; Thu, 15 Sep 2005 18:38:30 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8FIcUhP155216 for ; Thu, 15 Sep 2005 20:38:30 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8FIcUXV031624 for ; Thu, 15 Sep 2005 20:38:30 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8FIcU0A031621 for ; Thu, 15 Sep 2005 20:38:30 +0200 In-Reply-To: <004301c5b9f9$26332b10$0a031eac@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Thu, 15 Sep 2005 21:38:28 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 15/09/2005 21:38:29, Serialize complete at 15/09/2005 21:38:29 X-Spam-Score: 0.8 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1196187333==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1196187333== Content-Type: multipart/alternative; boundary="=_alternative 00652107C225707D_=" This is a multipart message in MIME format. --=_alternative 00652107C225707D_= Content-Type: text/plain; charset="US-ASCII" Eddy, The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering. Ordering within sequence is governed by DataPDUinOrder. Julo "Eddy Quicksall" Sent by: ips-bounces@ietf.org 15-09-05 16:26 To cc Subject [Ips] DataSequenceInOrder for non-immediate unsolicited 12.9 DataSequenceInOrder If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00652107C225707D_= Content-Type: text/html; charset="US-ASCII"
Eddy,

The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering.
Ordering within sequence is governed by DataPDUinOrder.



Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

15-09-05 16:26

To
<ips@ietf.org>
cc
Subject
[Ips] DataSequenceInOrder for non-immediate unsolicited





12.9 DataSequenceInOrder
 
   If DataSequenceInOrder is set to Yes, Data Sequences MUST be
  transferred using continuously non-decreasing sequence offsets (R2T
  buffer offset for writes, or the smallest SCSI Data-In buffer offset
  within a read data sequence).
 
Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation?
 
Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00652107C225707D_=-- --===============1196187333== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1196187333==-- From ips-bounces@ietf.org Thu Sep 15 19:04:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG2mj-0002Vb-DL; Thu, 15 Sep 2005 19:04:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG2mg-0002TI-Lq for ips@megatron.ietf.org; Thu, 15 Sep 2005 19:04:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17024 for ; Thu, 15 Sep 2005 19:04:47 -0400 (EDT) Received: from sccrmhc11.comcast.net ([63.240.76.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG2rX-0001Ti-Og for ips@ietf.org; Thu, 15 Sep 2005 19:09:54 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc11) with SMTP id <2005091523043801100pimd1e>; Thu, 15 Sep 2005 23:04:38 +0000 Message-ID: <00e801c5ba49$d9255a90$0a031eac@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Date: Thu, 15 Sep 2005 19:04:37 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: ips@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0379220993==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0379220993== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01C5BA28.51870AF0" This is a multi-part message in MIME format. ------=_NextPart_000_00E5_01C5BA28.51870AF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I understand that. My question is "does this also apply to non-immediate = unsolicited"? I think the answer is yes but I need to get a = clarification on that. Perhaps Mallikarjun could change it to (unsolicited and R2T ... ). Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Thursday, September 15, 2005 2:38 PM Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Eddy,=20 The unsolicited data start at offset zero. DataSequenceInOrder governs = only the sequence ordering.=20 Ordering within sequence is governed by DataPDUinOrder.=20 Julo=20 "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 15-09-05 16:26=20 To =20 cc =20 Subject [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 12.9 DataSequenceInOrder=20 =20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 =20 Up to the paren, this seems to apply to even non-immediate unsolicited = but there is a slight implication here, by distinctly referencing the = R2T, that this may not apply to non-immediate unsolicited PDUs. What is = the correct interpretation?=20 =20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_00E5_01C5BA28.51870AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I understand that. My question is "does this also = apply to=20 non-immediate unsolicited"? I think the answer is yes but I need = to get a=20 clarification on that.
 
Perhaps Mallikarjun could change it to (unsolicited = and R2T=20 ... ).
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Sent: Thursday, September 15, = 2005 2:38=20 PM
Subject: Re: [Ips] = DataSequenceInOrder=20 for non-immediate unsolicited

Eddy,

The = unsolicited data=20 start at offset zero. DataSequenceInOrder governs only the sequence=20 ordering.
Ordering within = sequence is=20 governed by DataPDUinOrder.

Julo

"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20
Sent by: ips-bounces@ietf.org=20

15-09-05 16:26

To
<ips@ietf.org>=20
cc
Subject
[Ips] = DataSequenceInOrder for=20 non-immediate unsolicited


12.9=20 DataSequenceInOrder
 
   If DataSequenceInOrder is set to Yes, Data = Sequences MUST=20 be
  transferred using continuously non-decreasing sequence = offsets=20 (R2T
  buffer offset for writes, or the smallest SCSI Data-In = buffer=20 offset
  within a read data sequence).
 
Up to the paren, this seems = to apply to=20 even non-immediate unsolicited but there is a slight implication here, = by=20 distinctly referencing the R2T, that this may not apply to = non-immediate=20 unsolicited PDUs. What is the correct interpretation?
 
Eddy_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_00E5_01C5BA28.51870AF0-- --===============0379220993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0379220993==-- From ips-bounces@ietf.org Fri Sep 16 02:22:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG9cB-0001GA-Qh; Fri, 16 Sep 2005 02:22:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG9c9-0001Fm-Qd for ips@megatron.ietf.org; Fri, 16 Sep 2005 02:22:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26574 for ; Fri, 16 Sep 2005 02:22:24 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG9h6-00030F-IK for ips@ietf.org; Fri, 16 Sep 2005 02:27:33 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8G6M9O0170156 for ; Fri, 16 Sep 2005 06:22:09 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8G6M9dg070976 for ; Fri, 16 Sep 2005 08:22:09 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8G6M8OK018004 for ; Fri, 16 Sep 2005 08:22:09 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8G6M8XD018001; Fri, 16 Sep 2005 08:22:08 +0200 In-Reply-To: <00e801c5ba49$d9255a90$0a031eac@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Fri, 16 Sep 2005 09:22:04 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 16/09/2005 09:22:08, Serialize complete at 16/09/2005 09:22:08 X-Spam-Score: 0.6 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: ips@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1143335788==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1143335788== Content-Type: multipart/alternative; boundary="=_alternative 00229545C225707E_=" This is a multipart message in MIME format. --=_alternative 00229545C225707E_= Content-Type: text/plain; charset="US-ASCII" The unsolicited data is always in order (it always start at offset zero). What has to apply? Why should Mallikarjun add the text? What is the question (please reformulate I have trouble understanding your point). Julo "Eddy Quicksall" 16-09-05 02:04 To Julian Satran/Haifa/IBM@IBMIL cc , "Mallikarjun C." Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited I understand that. My question is "does this also apply to non-immediate unsolicited"? I think the answer is yes but I need to get a clarification on that. Perhaps Mallikarjun could change it to (unsolicited and R2T ... ). Eddy ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ietf.org Sent: Thursday, September 15, 2005 2:38 PM Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Eddy, The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering. Ordering within sequence is governed by DataPDUinOrder. Julo "Eddy Quicksall" Sent by: ips-bounces@ietf.org 15-09-05 16:26 To cc Subject [Ips] DataSequenceInOrder for non-immediate unsolicited 12.9 DataSequenceInOrder If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00229545C225707E_= Content-Type: text/html; charset="US-ASCII"
The unsolicited data is always in order (it always start at offset zero). What has to apply? Why should Mallikarjun add the text? What is the question (please reformulate I have trouble understanding your point).

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 02:04

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, "Mallikarjun C." <cbm@rose.hp.com>
Subject
Re: [Ips] DataSequenceInOrder for non-immediate unsolicited





I understand that. My question is "does this also apply to non-immediate unsolicited"? I think the answer is yes but I need to get a clarification on that.
 
Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).
 
Eddy
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ietf.org
Sent: Thursday, September 15, 2005 2:38 PM
Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited

Eddy,

The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering.
Ordering within sequence is governed by DataPDUinOrder.

Julo
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

15-09-05 16:26


To
<ips@ietf.org>
cc
Subject
[Ips] DataSequenceInOrder for non-immediate unsolicited




12.9 DataSequenceInOrder
 
  If DataSequenceInOrder is set to Yes, Data Sequences MUST be
 transferred using continuously non-decreasing sequence offsets (R2T
 buffer offset for writes, or the smallest SCSI Data-In buffer offset
 within a read data sequence).
 
Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation?
 
Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 00229545C225707E_=-- --===============1143335788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1143335788==-- From ips-bounces@ietf.org Fri Sep 16 03:10:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGAMx-00047K-Du; Fri, 16 Sep 2005 03:10:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGAMr-00046w-A2 for ips@megatron.ietf.org; Fri, 16 Sep 2005 03:10:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28794 for ; Fri, 16 Sep 2005 03:10:39 -0400 (EDT) Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGARn-0004AS-Jh for ips@ietf.org; Fri, 16 Sep 2005 03:15:49 -0400 Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 16 Sep 2005 12:46:23 -0700 Received: from ind-mira-01.cisco.com (IDENT:mirapoint@ind-mira-01.cisco.com [64.104.129.12]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8G7A8bG016300; Fri, 16 Sep 2005 07:10:10 GMT Received: from surekhapw2k (dhcp-10-77-7-131.cisco.com [10.77.7.131]) by ind-mira-01.cisco.com (MOS 3.4.6-GR) with ESMTP id ANE24572; Fri, 16 Sep 2005 12:28:36 +0530 (IST) Message-Id: <200509160658.ANE24572@ind-mira-01.cisco.com> From: "Surekha.PC" To: "'Julian Satran'" , "'Eddy Quicksall'" Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited Date: Fri, 16 Sep 2005 12:40:20 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcW6hZ7xA5Na4x7xSp+O0FFUUY0+hQABAysw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.8 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 Cc: ips@ietf.org, "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0088157094==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0088157094== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F9_01C5BABB.CD1D7E40" This is a multi-part message in MIME format. ------=_NextPart_000_00F9_01C5BABB.CD1D7E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Eddy, I think DataSequenceInOrder "does not apply to non-immediate unsolicited Data PDUs" since only the first outgoing sequence can be sent unsolicited, it always starts at offset 0 and is in order as mentioned by Julian. 3.5.1.5 SCSI Data-out and SCSI Data-in An outgoing sequence is either unsolicited (only the first sequence can be unsolicited) or consists of all the Data-Out PDUs sent in response to an R2T. So in my opinion the below text rightly says "DataSequenceInOrder applies only to R2T and SCSI Data in buffer offsets". Hence I think there is no need for a change. ---------------------------------------------------------------------------------------------------- 12.9 DataSequenceInOrder If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). ---------------------------------------------------------------------------------------------------- -- Pls let me know your comments. Thanks, Surekha _____ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran Sent: Friday, September 16, 2005 11:52 AM To: Eddy Quicksall Cc: ips@ietf.org; Mallikarjun C. Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The unsolicited data is always in order (it always start at offset zero). What has to apply? Why should Mallikarjun add the text? What is the question (please reformulate I have trouble understanding your point). Julo "Eddy Quicksall" 16-09-05 02:04 To Julian Satran/Haifa/IBM@IBMIL cc , "Mallikarjun C." Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited I understand that. My question is "does this also apply to non-immediate unsolicited"? I think the answer is yes but I need to get a clarification on that. Perhaps Mallikarjun could change it to (unsolicited and R2T ... ). Eddy ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ietf.org Sent: Thursday, September 15, 2005 2:38 PM Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Eddy, The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering. Ordering within sequence is governed by DataPDUinOrder. Julo "Eddy Quicksall" < eddy_quicksall_iVivity_iSCSI@comcast.net> Sent by: ips-bounces@ietf.org 15-09-05 16:26 To < ips@ietf.org> cc Subject [Ips] DataSequenceInOrder for non-immediate unsolicited 12.9 DataSequenceInOrder If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _____ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_00F9_01C5BABB.CD1D7E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eddy,
 
I think DataSequenceInOrder "does not = apply to=20 non-immediate unsolicited Data PDUs" since only the first outgoing = sequence=20 can be sent unsolicited, it always starts at offset 0 and is in = order as=20 mentioned by Julian.
 
3.5.1.5 SCSI Data-out and SCSI = Data-in
An outgoing sequence is either unsolicited=20 (only the first sequence can be unsolicited) or = consists of all=20 the Data-Out PDUs sent in response to an=20 R2T.
So in=20 my opinion the below text rightly says "DataSequenceInOrder = applies=20 only to R2T and SCSI Data in buffer offsets". Hence I think there is=20 no need for a change.
 
----------------------------------------------------------------= ------------------------------------
12.9=20 DataSequenceInOrder
 
 =20 If DataSequenceInOrder is set to Yes, Data Sequences MUST=20 be
 transferred using continuously non-decreasing sequence = offsets=20 (R2T
 buffer offset for writes, or the smallest SCSI Data-In = buffer=20 offset
 within a read data sequence).=20
----------------------------------------------------------------= --------------------------------------
 
Pls=20 let me know your comments.
 
Thanks,
Surekha
 
From: ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of Julian=20 Satran
Sent: Friday, September 16, 2005 11:52 = AM
To: Eddy=20 Quicksall
Cc: ips@ietf.org; Mallikarjun = C.
Subject: Re:=20 [Ips] DataSequenceInOrder for non-immediate = unsolicited


The unsolicited=20 data is always in order (it always start at offset zero). What has to = apply?=20 Why should Mallikarjun add the text? What is the question (please = reformulate=20 I have trouble understanding your point).

Julo


"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 02:04

To
Julian=20 Satran/Haifa/IBM@IBMIL=20
cc
<ips@ietf.org>,=20 "Mallikarjun C." <cbm@rose.hp.com>=20
Subject
Re: [Ips] = DataSequenceInOrder for=20 non-immediate unsolicited

=




I=20 understand that. My question is "does this also apply to non-immediate = unsolicited"? I think the answer is yes but I need to get a = clarification on=20 that.
 
Perhaps=20 Mallikarjun could change it to (unsolicited and R2T ... ). =
 
Eddy
-----=20 Original Message -----
From: = Julian=20 Satran
To:=20 Eddy Quicksall=20
Cc: ips@ietf.org =
Sent: Thursday, September 15, 2005 2:38 PM =
Subject: Re: [Ips] DataSequenceInOrder for = non-immediate=20 unsolicited

Eddy,

The = unsolicited data start=20 at offset zero. DataSequenceInOrder governs only the sequence=20 ordering.
Ordering=20 within sequence is governed by DataPDUinOrder.

Julo=20
"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org =

15-09-05 16:26=20


To
<ips@ietf.org>
cc
Subject
[Ips] = DataSequenceInOrder for=20 non-immediate = unsolicited




12.9 DataSequenceInOrder =
 
  If DataSequenceInOrder is set to Yes, Data = Sequences MUST=20 be
 transferred using continuously non-decreasing sequence = offsets=20 (R2T
 buffer offset for writes, or the smallest SCSI Data-In = buffer=20 offset
 within a read data sequence).=20
 
Up to the paren, this seems to = apply to even=20 non-immediate unsolicited but there is a slight implication here, by=20 distinctly referencing the R2T, that this may not apply to = non-immediate=20 unsolicited PDUs. What is the correct interpretation?=20
 
Eddy_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips= =20

------=_NextPart_000_00F9_01C5BABB.CD1D7E40-- --===============0088157094== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0088157094==-- From ips-bounces@ietf.org Fri Sep 16 09:54:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGfJ-0004uv-KD; Fri, 16 Sep 2005 09:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGGfI-0004ul-3q for ips@megatron.ietf.org; Fri, 16 Sep 2005 09:54:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18024 for ; Fri, 16 Sep 2005 09:54:05 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGGkI-0006xa-AI for ips@ietf.org; Fri, 16 Sep 2005 09:59:19 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j8GDrpin000793 for ; Fri, 16 Sep 2005 09:53:51 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j8GDroje000788; Fri, 16 Sep 2005 09:53:50 -0400 Received: from PKONING.equallogic.com ([172.16.1.186]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 09:53:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17194.52844.863000.648829@gargle.gargle.HOWL> Date: Fri, 16 Sep 2005 09:53:48 -0400 From: Paul Koning To: surekhap@cisco.com Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited References: <200509160658.ANE24572@ind-mira-01.cisco.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 16 Sep 2005 13:53:50.0971 (UTC) FILETIME=[117E54B0:01C5BAC6] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org, eddy_quicksall_iVivity_iSCSI@comcast.net, Julian_Satran@il.ibm.com, cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Surekha" == Surekha PC writes: Surekha> Hi Eddy, I think DataSequenceInOrder "does not apply to Surekha> non-immediate unsolicited Data PDUs" since only the first Surekha> outgoing sequence can be sent unsolicited, it always starts Surekha> at offset 0 and is in order as mentioned by Julian. Surekha> 3.5.1.5 SCSI Data-out and SCSI Data-in An outgoing sequence Surekha> is either unsolicited (only the first sequence can be Surekha> unsolicited) or consists of all the Data-Out PDUs sent in Surekha> response to an R2T. That text says "starts at offset 0" but it doesn't say "always in order". paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 16 10:41:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHP9-0008Kk-Gb; Fri, 16 Sep 2005 10:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHP8-0008Kc-Fr for ips@megatron.ietf.org; Fri, 16 Sep 2005 10:41:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21191 for ; Fri, 16 Sep 2005 10:41:27 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGHU6-00083F-IX for ips@ietf.org; Fri, 16 Sep 2005 10:46:42 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc14) with SMTP id <2005091614411001400ojfgbe>; Fri, 16 Sep 2005 14:41:11 +0000 Message-ID: <001401c5bacc$aee62420$0a031eac@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Date: Fri, 16 Sep 2005 10:41:05 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 Cc: ips@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0650394537==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0650394537== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C5BAAB.23D59120" This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C5BAAB.23D59120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My point is that the information in parens mentions two things = specifically (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). Since there is no "e.g." then this = implies that these two things are the ones he is talking about. What I'm saying is that if it were changed to say: (non-immediate unsolicited, R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence) then there would be no ambiguity. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org ; Mallikarjun C.=20 Sent: Friday, September 16, 2005 2:22 AM Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The unsolicited data is always in order (it always start at offset = zero). What has to apply? Why should Mallikarjun add the text? What is = the question (please reformulate I have trouble understanding your = point).=20 Julo=20 "Eddy Quicksall" =20 16-09-05 02:04=20 To Julian Satran/Haifa/IBM@IBMIL =20 cc , "Mallikarjun C." =20 Subject Re: [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 I understand that. My question is "does this also apply to = non-immediate unsolicited"? I think the answer is yes but I need to get = a clarification on that.=20 =20 Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Thursday, September 15, 2005 2:38 PM=20 Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited=20 Eddy,=20 The unsolicited data start at offset zero. DataSequenceInOrder governs = only the sequence ordering.=20 Ordering within sequence is governed by DataPDUinOrder.=20 Julo=20 "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 15-09-05 16:26=20 =20 To =20 cc =20 Subject [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 12.9 DataSequenceInOrder=20 =20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 =20 Up to the paren, this seems to apply to even non-immediate unsolicited = but there is a slight implication here, by distinctly referencing the = R2T, that this may not apply to non-immediate unsolicited PDUs. What is = the correct interpretation?=20 =20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_000A_01C5BAAB.23D59120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My point is that the information in parens mentions = two things=20 specifically (R2T
 buffer offset for writes, or the smallest = SCSI=20 Data-In buffer offset
 within a read data sequence). Since there = is no=20 "e.g." then this implies that these two things are the ones he is = talking=20 about.
 
What I'm saying is that if it were changed to=20 say:
 
(non-immediate unsolicited, R2T
 buffer = offset for=20 writes, or the smallest SCSI Data-In buffer offset
 within a = read data=20 sequence)
 
then there would be no ambiguity.
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy = Quicksall=20
Sent: Friday, September 16, = 2005 2:22=20 AM
Subject: Re: [Ips] = DataSequenceInOrder=20 for non-immediate unsolicited


The unsolicited = data is always=20 in order (it always start at offset zero). What has to apply? Why = should=20 Mallikarjun add the text? What is the question (please reformulate I = have=20 trouble understanding your point).

Julo


"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20

16-09-05 02:04

To
Julian Satran/Haifa/IBM@IBMIL =
cc
<ips@ietf.org>, = "Mallikarjun C."=20 <cbm@rose.hp.com>=20
Subject
Re: [Ips] = DataSequenceInOrder for=20 non-immediate unsolicited

=




I=20 understand that. My question is "does this also apply to non-immediate = unsolicited"? I think the answer is yes but I need to get a = clarification on=20 that.
 
Perhaps=20 Mallikarjun could change it to (unsolicited and R2T ... ). =
 
Eddy
-----=20 Original Message -----
From: = Julian=20 Satran
To:=20 Eddy Quicksall=20
Cc: ips@ietf.org =
Sent: Thursday, September 15, 2005 2:38 PM =
Subject: Re: [Ips] DataSequenceInOrder for = non-immediate=20 unsolicited

Eddy,

The = unsolicited data start=20 at offset zero. DataSequenceInOrder governs only the sequence=20 ordering.
Ordering=20 within sequence is governed by DataPDUinOrder.

Julo=20
"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org =

15-09-05 16:26=20


To
<ips@ietf.org>
cc
Subject
[Ips] = DataSequenceInOrder for=20 non-immediate = unsolicited




12.9 DataSequenceInOrder =
 
  If DataSequenceInOrder is set to Yes, Data = Sequences MUST=20 be
 transferred using continuously non-decreasing sequence = offsets=20 (R2T
 buffer offset for writes, or the smallest SCSI Data-In = buffer=20 offset
 within a read data sequence).=20
 
Up to the paren, this seems to = apply to even=20 non-immediate unsolicited but there is a slight implication here, by=20 distinctly referencing the R2T, that this may not apply to = non-immediate=20 unsolicited PDUs. What is the correct interpretation?=20
 
Eddy_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips= =20

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_000A_01C5BAAB.23D59120-- --===============0650394537== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0650394537==-- From ips-bounces@ietf.org Fri Sep 16 10:44:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHRz-0000e6-Ua; Fri, 16 Sep 2005 10:44:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHRx-0000e1-VX for ips@megatron.ietf.org; Fri, 16 Sep 2005 10:44:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21339 for ; Fri, 16 Sep 2005 10:44:23 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGHWz-00087u-7w for ips@ietf.org; Fri, 16 Sep 2005 10:49:38 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc14) with SMTP id <2005091614440101400oikene>; Fri, 16 Sep 2005 14:44:01 +0000 Message-ID: <002201c5bacd$1434e500$0a031eac@ivivity.com> From: "Eddy Quicksall" To: "Surekha.PC" , "'Julian Satran'" References: <200509160658.ANE24572@ind-mira-01.cisco.com> Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Date: Fri, 16 Sep 2005 10:44:00 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: 19c92f723dac1bcdd68591cc46e38e95 Cc: ips@ietf.org, "'Mallikarjun C.'" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1547453562==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1547453562== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C5BAAB.8C706FC0" This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C5BAAB.8C706FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The non-immediate unsolicited could be received out of order by the = following events: I-T Command T-I R2T If the initiator receives the R2T before it has begun to send the = non-immediate unsolicited then, if DataSequenceInOrder is no, it could = send the solicited data before sending the non-immediate unsolicited. Eddy ----- Original Message -----=20 From: Surekha.PC=20 To: 'Julian Satran' ; 'Eddy Quicksall'=20 Cc: ips@ietf.org ; 'Mallikarjun C.'=20 Sent: Friday, September 16, 2005 3:10 AM Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited Hi Eddy, I think DataSequenceInOrder "does not apply to non-immediate = unsolicited Data PDUs" since only the first outgoing sequence can be = sent unsolicited, it always starts at offset 0 and is in order as = mentioned by Julian. 3.5.1.5 SCSI Data-out and SCSI Data-in An outgoing sequence is either unsolicited (only the first sequence = can be unsolicited) or consists of all the Data-Out PDUs sent in = response to an R2T. So in my opinion the below text rightly says "DataSequenceInOrder = applies only to R2T and SCSI Data in buffer offsets". Hence I think = there is no need for a change. = -------------------------------------------------------------------------= --------------------------- 12.9 DataSequenceInOrder=20 =20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 = -------------------------------------------------------------------------= ----------------------------- Pls let me know your comments. Thanks, Surekha -------------------------------------------------------------------------= --- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf = Of Julian Satran Sent: Friday, September 16, 2005 11:52 AM To: Eddy Quicksall Cc: ips@ietf.org; Mallikarjun C. Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The unsolicited data is always in order (it always start at offset = zero). What has to apply? Why should Mallikarjun add the text? What is = the question (please reformulate I have trouble understanding your = point).=20 Julo=20 "Eddy Quicksall" =20 16-09-05 02:04=20 To Julian Satran/Haifa/IBM@IBMIL =20 cc , "Mallikarjun C." =20 Subject Re: [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 I understand that. My question is "does this also apply to = non-immediate unsolicited"? I think the answer is yes but I need to get = a clarification on that.=20 =20 Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Thursday, September 15, 2005 2:38 PM=20 Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited = Eddy,=20 The unsolicited data start at offset zero. DataSequenceInOrder = governs only the sequence ordering.=20 Ordering within sequence is governed by DataPDUinOrder.=20 Julo=20 "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 15-09-05 16:26=20 =20 To =20 cc =20 Subject [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 12.9 DataSequenceInOrder=20 =20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer = offset within a read data sequence).=20 =20 Up to the paren, this seems to apply to even non-immediate = unsolicited but there is a slight implication here, by distinctly = referencing the R2T, that this may not apply to non-immediate = unsolicited PDUs. What is the correct interpretation?=20 =20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= --- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_001F_01C5BAAB.8C706FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The non-immediate unsolicited could be received out = of order=20 by the following events:
 
I-T Command
T-I R2T
 
If the initiator receives the R2T before it has = begun to send=20 the non-immediate unsolicited then, if DataSequenceInOrder is no, it = could send=20 the solicited data before sending the non-immediate = unsolicited.
 
Eddy
----- Original Message -----
From:=20 Surekha.PC=20
To: 'Julian Satran' ; 'Eddy = Quicksall'=20
Sent: Friday, September 16, = 2005 3:10=20 AM
Subject: RE: [Ips] = DataSequenceInOrder=20 for non-immediate unsolicited

Hi Eddy,
 
I think DataSequenceInOrder "does = not apply to=20 non-immediate unsolicited Data PDUs" since only the first = outgoing=20 sequence can be sent unsolicited, it always starts at offset 0 = and is in=20 order as mentioned by Julian.
 
3.5.1.5 SCSI Data-out and SCSI=20 Data-in
An outgoing sequence is either unsolicited=20 (only the first sequence can be unsolicited) or = consists of=20 all the Data-Out PDUs sent in response to an=20 R2T.
So=20 in my opinion the below text rightly says = "DataSequenceInOrder=20 applies only to R2T and SCSI Data in buffer offsets". Hence I think = there is=20 no need for a change.
 
----------------------------------------------------------------= ------------------------------------
12.9=20 DataSequenceInOrder
 
  If DataSequenceInOrder is set to Yes, Data = Sequences MUST=20 be
 transferred using continuously non-decreasing sequence = offsets=20 (R2T
 buffer offset for writes, or the smallest SCSI Data-In = buffer=20 offset
 within a read data sequence).=20
----------------------------------------------------------------= --------------------------------------
 
Pls=20 let me know your comments.
 
Thanks,
Surekha
 
From: ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of Julian=20 Satran
Sent: Friday, September 16, 2005 11:52 = AM
To:=20 Eddy Quicksall
Cc: ips@ietf.org; Mallikarjun = C.
Subject:=20 Re: [Ips] DataSequenceInOrder for non-immediate=20 unsolicited


The unsolicited = data is=20 always in order (it always start at offset zero). What has to apply? = Why=20 should Mallikarjun add the text? What is the question (please = reformulate I=20 have trouble understanding your point).

Julo


"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 02:04

To
Julian=20 Satran/Haifa/IBM@IBMIL=20
cc
<ips@ietf.org>, = "Mallikarjun C." <cbm@rose.hp.com>=20
Subject
Re: [Ips] = DataSequenceInOrder=20 for non-immediate = unsolicited

=




<= FONT=20 size=3D2>I understand that. My question is "does this also apply to=20 non-immediate unsolicited"? I think the answer is yes but I need to = get a=20 clarification on that.
  =
Perhaps Mallikarjun could change it to (unsolicited and R2T = ...=20 ).
 
Eddy=20
----- Original Message -----
From: Julian Satran =
To: Eddy Quicksall =
Cc: ips@ietf.org =
Sent: Thursday, September 15, 2005 2:38 PM =
Subject: Re: [Ips] DataSequenceInOrder for = non-immediate=20 unsolicited

Eddy,

The = unsolicited data=20 start at offset zero. DataSequenceInOrder governs only the sequence=20 ordering.
Ordering within sequence is governed by DataPDUinOrder. =

Julo
"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org =

15-09-05 16:26=20


To
<ips@ietf.org>
cc
Subject
[Ips] = DataSequenceInOrder for=20 non-immediate = unsolicited



12.9 DataSequenceInOrder =
 
  If DataSequenceInOrder is set to Yes, Data = Sequences MUST=20 be
 transferred using continuously non-decreasing sequence = offsets=20 (R2T
 buffer offset for writes, or the smallest SCSI Data-In = buffer=20 offset
 within a read data sequence).=20
 
Up to the paren, this seems to = apply to=20 even non-immediate unsolicited but there is a slight implication = here, by=20 distinctly referencing the R2T, that this may not apply to = non-immediate=20 unsolicited PDUs. What is the correct interpretation?=20
 
Eddy_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips= =20

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_001F_01C5BAAB.8C706FC0-- --===============1547453562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1547453562==-- From ips-bounces@ietf.org Fri Sep 16 11:02:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHjf-00052H-Ua; Fri, 16 Sep 2005 11:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHje-00051l-67 for ips@megatron.ietf.org; Fri, 16 Sep 2005 11:02:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22138 for ; Fri, 16 Sep 2005 11:02:39 -0400 (EDT) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGHof-00008L-O1 for ips@ietf.org; Fri, 16 Sep 2005 11:07:54 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 32902280B for ; Fri, 16 Sep 2005 11:02:40 -0400 (EDT) Received: from [127.0.0.1] (unknown [15.244.203.105]) by rosemail.rose.hp.com (Postfix) with ESMTP id DD0C58057 for ; Fri, 16 Sep 2005 07:52:33 -0700 (PDT) Message-ID: <432ADE8F.1010805@rose.hp.com> Date: Fri, 16 Sep 2005 08:02:39 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'IPS'" Subject: Re: [Ips] Discovery text References: <002001c5b9db$5c6163f0$ac07a8c0@elipsan.com> In-Reply-To: <002001c5b9db$5c6163f0$ac07a8c0@elipsan.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org All, Thanks for the review, I will make the MUST->SHOULD, and Portal->Network Portal changes as suggested. Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Ken Sandars wrote: > Hi Mallikarjun, > > Great work on the rewrite of this text. Due to technical difficulties I > never saw the original post, so I'm glad Bill replied! I agree with Bill's > tweak, too. > > Cheers, > Ken > > >>-----Original Message----- >>From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On >>Behalf Of William Studenmund >>Sent: 12 September 2005 01:50 >>To: Mallikarjun C. >>Cc: IPS >>Subject: Re: [Ips] Discovery text >> >> >>On Sep 9, 2005, at 5:22 PM, Mallikarjun C. wrote: >> >> >>>The new proposed text is attached below. >> >>I have a minor comment (below), but overall, LOOKS GREAT! >> >> >>>I intend to shortly publish a -01 revision with several updates, >>>including this one subject to agreement (which I hope >> >>exists based on >> >>>the threads so far....). >>> >>>Mallikarjun >>> >>>Mallikarjun Chadalapaka >>>Networked Storage Architecture >>>StorageWorks Division >>>Hewlett-Packard MS 5668 >>>Roseville CA 95747 >>>cbm [at] rose.hp.com >>> >>> >>>5 Discovery semantics >>>5.1 Error Recovery for Discovery Sessions >>>The negotiation of the key ErrorRecoveryLevel is irrelevant for >>>Discovery sessions - i.e. for sessions that negotiated >>>"SessionType=Discovery". The operational ErrorRecoveryLevel for >>>Discovery sessions MUST be 0. This naturally follows from the >>>functionality constraints [RFC3720] imposes on Discovery sessions. >>> >>>5.2 Discovery Philosophy and Reinstatement >>>Discovery sessions are intended to be relatively short-lived. >>>Initiators are not expected to establish multiple Discovery >> >>sessions >> >>>to the same iSCSI Portal (see [RFC3720]). An initiator may use the >>>same iSCSI Initiator Name and ISID when establishing >> >>different unique >> >>>sessions with different targets and/or different portal >> >>groups. This >> >>>behavior is discussed in Section 9.1.1 of [RFC3720] and is, >> >>in fact, >> >>>encouraged as conservative reuse of ISIDs. ISID RULE in [RFC3720] >>>states that there must not be more than one session with a matching >>>4-tuple: . >>>While the spirit of the ISID RULE applies to Discovery sessions the >>>same as it does for Normal sessions, note that some >> >>Discovery sessions >> >>>differ from the Normal sessions in two important aspects: >>>* Because [RFC3720] allows a Discovery session to be established >>>without specifying a TargetName key in the Login Request >> >>PDU (let us >> >>>call such a session an "Unnamed" Discovery session), there is no >>>Target Node context to enforce the ISID RULE. >>>* Portal Groups are defined only in the context of a >> >>Target Node. >> >>>When the TargetName key is NULL-valued (i.e. not specified), the >>>TargetPortalGroupTag thus cannot be ascertained to enforce the ISID >>>RULE. >>> >>>The following sections describe the two scenarios - Named Discovery >>>sessions and Unnamed Discovery sessions - separately. >>> >>>5.2.1 Unnamed Discovery Sessions >>>For Unnamed Discovery sessions, neither the TargetName nor the >>>TargetPortalGroupTag is available to the targets in order >> >>to enforce >> >>>the ISID RULE. So the following rule applies. >>> >>>UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the >>>following 4-tuple for Unnamed Discovery sessions: >>ISID, NULL, TargetAddress>. The following semantics are implied by >>>this uniqueness requirement. >>> >>>Resources permitting, targets MUST allow concurrent >> >>establishment of >> >>>one Discovery session with each of its >> >>I'm not sure if we're supposed to use "MUST" like this. I think >>"SHOULD" is the correct word; we definitely think the target must do >>this, but realize there may be an occasion in which it can't. >> >> >>>Portals by the same initiator port with a given iSCSI Node >> >>Name and an >> >>>ISID. Each of the concurrent Discovery sessions, if established by >>>the same initiator port, MUST be treated as independent sessions - >>>i.e. one session MUST NOT reinstate the other. >>> >>>A new Unnamed Discovery session that has a matching >>ISID, NULL, TargetAddress> to an existing discovery session MUST >>>reinstate the existing Unnamed Discovery session. Note >> >>thus that only >> >>>an Unnamed Discovery session may reinstate an Unnamed Discovery >>>session. >>> >>>5.2.2 Named Discovery Sessions >>>For a Named Discovery session, the TargetName key is >> >>specified by the >> >>>initiator and thus the target can unambiguously ascertain the >>>TargetPortalGroupTag as well. Since all the four elements of the >>>4-tuple are known, the ISID RULE MUST be enforced by >> >>targets with no >> >>>changes from [RFC3720] semantics. A new session with a matching >>> thus will >>>reinstate an existing session. Note in this case that any >> >>new iSCSI >> >>>session (Discovery or Normal) with the matching 4-tuple may >> >>reinstate >> >>>an existing Named Discovery iSCSI session. >> >>Take care, >> >>Bill >> > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 16 11:26:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGI6S-0003UY-4e; Fri, 16 Sep 2005 11:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGI6P-0003QP-Sj for ips@megatron.ietf.org; Fri, 16 Sep 2005 11:26:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23817 for ; Fri, 16 Sep 2005 11:26:10 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGIBP-0000xk-SU for ips@ietf.org; Fri, 16 Sep 2005 11:31:26 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8GFQ28K023859 for ; Fri, 16 Sep 2005 11:26:02 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8GFQ2Ia057920 for ; Fri, 16 Sep 2005 11:26:02 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8GFPxTe003949 for ; Fri, 16 Sep 2005 11:25:59 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8GFPxx0003942 for ; Fri, 16 Sep 2005 11:25:59 -0400 Importance: Normal MIME-Version: 1.0 To: ips@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Fri, 16 Sep 2005 08:25:57 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 7.0HF2 | September 9, 2005) at 09/16/2005 11:25:58, Serialize complete at 09/16/2005 11:25:58 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ips] iSER-05 draft candidate X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I have updated the iSER draft incorporating the changes as suggested in draft-hufferd-iser-ib-01.txt. With thanks to Julian Satran, you can download both the text version (draft-ietf-ips-iser-05_candidate.txt) and a PDF version showing the changes (draft-ieft-ips-iser-05_candidate.pdf) from his website at http://www.haifa.il.ibm.com/satran/ips/ Note that these are not official IETF releases and are merely interim versions for discussion purposes only. Other than typos, all major changes to the iSER draft are documented in draft-hufferd-iser-ib-01.txt. Mike _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 16 12:48:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJO8-0000cN-O6; Fri, 16 Sep 2005 12:48:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJO6-0000c6-DO for ips@megatron.ietf.org; Fri, 16 Sep 2005 12:48:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28495 for ; Fri, 16 Sep 2005 12:48:28 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGJT3-0003NI-CP for ips@ietf.org; Fri, 16 Sep 2005 12:53:44 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8GGmDO0133768 for ; Fri, 16 Sep 2005 16:48:13 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8GGmCdg180888 for ; Fri, 16 Sep 2005 18:48:12 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8GGmCXr019357 for ; Fri, 16 Sep 2005 18:48:12 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8GGmCQ2019354; Fri, 16 Sep 2005 18:48:12 +0200 In-Reply-To: <17194.52844.863000.648829@gargle.gargle.HOWL> To: Paul Koning Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Fri, 16 Sep 2005 19:48:09 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 16/09/2005 19:48:11, Serialize complete at 16/09/2005 19:48:11 X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ips@ietf.org, eddy_quicksall_iVivity_iSCSI@comcast.net, cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1427909727==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1427909727== Content-Type: multipart/alternative; boundary="=_alternative 005AC10AC225707E_=" This is a multipart message in MIME format. --=_alternative 005AC10AC225707E_= Content-Type: text/plain; charset="US-ASCII" There is only one unsolicited sequence and it is the first and starting with 0 makes it ordered always. I am bit tired about all this gibberish. Julo Paul Koning 16-09-05 16:53 To surekhap@cisco.com cc Julian Satran/Haifa/IBM@IBMIL, eddy_quicksall_iVivity_iSCSI@comcast.net, ips@ietf.org, cbm@rose.hp.com Subject RE: [Ips] DataSequenceInOrder for non-immediate unsolicited >>>>> "Surekha" == Surekha PC writes: Surekha> Hi Eddy, I think DataSequenceInOrder "does not apply to Surekha> non-immediate unsolicited Data PDUs" since only the first Surekha> outgoing sequence can be sent unsolicited, it always starts Surekha> at offset 0 and is in order as mentioned by Julian. Surekha> 3.5.1.5 SCSI Data-out and SCSI Data-in An outgoing sequence Surekha> is either unsolicited (only the first sequence can be Surekha> unsolicited) or consists of all the Data-Out PDUs sent in Surekha> response to an R2T. That text says "starts at offset 0" but it doesn't say "always in order". paul --=_alternative 005AC10AC225707E_= Content-Type: text/html; charset="US-ASCII"
There is only one unsolicited sequence and it is the first and starting with 0 makes it ordered always.
I am bit tired about all this gibberish.

Julo


Paul Koning <pkoning@equallogic.com>

16-09-05 16:53

To
surekhap@cisco.com
cc
Julian Satran/Haifa/IBM@IBMIL, eddy_quicksall_iVivity_iSCSI@comcast.net, ips@ietf.org, cbm@rose.hp.com
Subject
RE: [Ips] DataSequenceInOrder for non-immediate unsolicited





>>>>> "Surekha" == Surekha PC <Surekha.PC> writes:

Surekha> Hi Eddy, I think DataSequenceInOrder "does not apply to
Surekha> non-immediate unsolicited Data PDUs" since only the first
Surekha> outgoing sequence can be sent unsolicited, it always starts
Surekha> at offset 0 and is in order as mentioned by Julian.

Surekha> 3.5.1.5 SCSI Data-out and SCSI Data-in An outgoing sequence
Surekha> is either unsolicited (only the first sequence can be
Surekha> unsolicited) or consists of all the Data-Out PDUs sent in
Surekha> response to an R2T.

That text says "starts at offset 0" but it doesn't say "always in
order".

                paul
--=_alternative 005AC10AC225707E_=-- --===============1427909727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1427909727==-- From ips-bounces@ietf.org Fri Sep 16 12:48:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJOA-0000cr-Dh; Fri, 16 Sep 2005 12:48:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJO6-0000c5-D1 for ips@megatron.ietf.org; Fri, 16 Sep 2005 12:48:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28499 for ; Fri, 16 Sep 2005 12:48:29 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGJT4-0003NM-5Y for ips@ietf.org; Fri, 16 Sep 2005 12:53:46 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8GGmFd7196382 for ; Fri, 16 Sep 2005 16:48:15 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8GGmEdg170444 for ; Fri, 16 Sep 2005 18:48:14 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8GGmEBi014531 for ; Fri, 16 Sep 2005 18:48:14 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8GGmEaU014528; Fri, 16 Sep 2005 18:48:14 +0200 To: ips@ietf.org Subject: Fw: [Ips] DataSequenceInOrder for non-immediate unsolicited MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Fri, 16 Sep 2005 19:48:10 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 16/09/2005 19:48:13, Serialize complete at 16/09/2005 19:48:13 X-Spam-Score: 0.9 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Cc: Eddy Quicksall , cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0135599300==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0135599300== Content-Type: multipart/alternative; boundary="=_alternative 005BB3D3C225707E_=" This is a multipart message in MIME format. --=_alternative 005BB3D3C225707E_= Content-Type: text/plain; charset="US-ASCII" That is not correct. The unsolicited data is a sequence and it has to be ended before anything else happens. Unsolicited data is equivalent to a "virtual R2T" with offset 0 and R2Ts have to be honored in order. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 16-09-05 19:37 ----- "Eddy Quicksall" 16-09-05 17:44 To "Surekha.PC" , Julian Satran/Haifa/IBM@IBMIL cc , "'Mallikarjun C.'" Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The non-immediate unsolicited could be received out of order by the following events: I-T Command T-I R2T If the initiator receives the R2T before it has begun to send the non-immediate unsolicited then, if DataSequenceInOrder is no, it could send the solicited data before sending the non-immediate unsolicited. Eddy ----- Original Message ----- From: Surekha.PC To: 'Julian Satran' ; 'Eddy Quicksall' Cc: ips@ietf.org ; 'Mallikarjun C.' Sent: Friday, September 16, 2005 3:10 AM Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited Hi Eddy, I think DataSequenceInOrder "does not apply to non-immediate unsolicited Data PDUs" since only the first outgoing sequence can be sent unsolicited, it always starts at offset 0 and is in order as mentioned by Julian. 3.5.1.5 SCSI Data-out and SCSI Data-in An outgoing sequence is either unsolicited (only the first sequence can be unsolicited) or consists of all the Data-Out PDUs sent in response to an R2T. So in my opinion the below text rightly says "DataSequenceInOrder applies only to R2T and SCSI Data in buffer offsets". Hence I think there is no need for a change. ---------------------------------------------------------------------------------------------------- 12.9 DataSequenceInOrder If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). ------------------------------------------------------------------------------------------------------ Pls let me know your comments. Thanks, Surekha From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran Sent: Friday, September 16, 2005 11:52 AM To: Eddy Quicksall Cc: ips@ietf.org; Mallikarjun C. Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The unsolicited data is always in order (it always start at offset zero). What has to apply? Why should Mallikarjun add the text? What is the question (please reformulate I have trouble understanding your point). Julo "Eddy Quicksall" 16-09-05 02:04 To Julian Satran/Haifa/IBM@IBMIL cc , "Mallikarjun C." Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited I understand that. My question is "does this also apply to non-immediate unsolicited"? I think the answer is yes but I need to get a clarification on that. Perhaps Mallikarjun could change it to (unsolicited and R2T ... ). Eddy ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ietf.org Sent: Thursday, September 15, 2005 2:38 PM Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Eddy, The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering. Ordering within sequence is governed by DataPDUinOrder. Julo "Eddy Quicksall" Sent by: ips-bounces@ietf.org 15-09-05 16:26 To cc Subject [Ips] DataSequenceInOrder for non-immediate unsolicited 12.9 DataSequenceInOrder If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005BB3D3C225707E_= Content-Type: text/html; charset="US-ASCII"
That is not correct. The unsolicited data is a sequence and it has to be ended before anything else happens. Unsolicited data is equivalent to a "virtual R2T" with offset 0
and R2Ts have to be honored in order.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 16-09-05 19:37 -----
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 17:44

To
"Surekha.PC" <surekhap@cisco.com>, Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, "'Mallikarjun C.'" <cbm@rose.hp.com>
Subject
Re: [Ips] DataSequenceInOrder for non-immediate unsolicited





The non-immediate unsolicited could be received out of order by the following events:
 
I-T Command
T-I R2T
 
If the initiator receives the R2T before it has begun to send the non-immediate unsolicited then, if DataSequenceInOrder is no, it could send the solicited data before sending the non-immediate unsolicited.
 
Eddy
----- Original Message -----
From: Surekha.PC
To: 'Julian Satran' ; 'Eddy Quicksall'
Cc: ips@ietf.org ; 'Mallikarjun C.'
Sent: Friday, September 16, 2005 3:10 AM
Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited

Hi Eddy,
 
I think DataSequenceInOrder "does not apply to non-immediate unsolicited Data PDUs" since only the first outgoing sequence can be sent unsolicited, it always starts at offset 0 and is in order as mentioned by Julian.
 
3.5.1.5 SCSI Data-out and SCSI Data-in
An outgoing sequence is either unsolicited (only the first sequence can be unsolicited) or consists of all the Data-Out PDUs sent in response to an R2T.
So in my opinion the below text rightly says "DataSequenceInOrder applies only to R2T and SCSI Data in buffer offsets". Hence I think there is no need for a change.
 
----------------------------------------------------------------------------------------------------
12.9 DataSequenceInOrder

 If DataSequenceInOrder is set to Yes, Data Sequences MUST be
transferred using continuously non-decreasing sequence offsets (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer offset
within a read data sequence).
------------------------------------------------------------------------------------------------------
 
Pls let me know your comments.
 
Thanks,
Surekha
 
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran
Sent: Friday, September 16, 2005 11:52 AM
To: Eddy Quicksall
Cc: ips@ietf.org; Mallikarjun C.
Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited

The unsolicited data is always in order (it always start at offset zero). What has to apply? Why should Mallikarjun add the text? What is the question (please reformulate I have trouble understanding your point).

Julo

"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 02:04


To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, "Mallikarjun C." <cbm@rose.hp.com>
Subject
Re: [Ips] DataSequenceInOrder for non-immediate unsolicited







I understand that. My question is "does this also apply to non-immediate unsolicited"? I think the answer is yes but I need to get a clarification on that.
 
Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).
 
Eddy
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ietf.org
Sent: Thursday, September 15, 2005 2:38 PM
Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited

Eddy,

The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering.
Ordering within sequence is governed by DataPDUinOrder.

Julo
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

15-09-05 16:26


To
<ips@ietf.org>
cc
Subject
[Ips] DataSequenceInOrder for non-immediate unsolicited



12.9 DataSequenceInOrder

 If DataSequenceInOrder is set to Yes, Data Sequences MUST be
transferred using continuously non-decreasing sequence offsets (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer offset
within a read data sequence).

Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation?

Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005BB3D3C225707E_=-- --===============0135599300== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0135599300==-- From ips-bounces@ietf.org Fri Sep 16 12:48:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJOJ-0000e2-3D; Fri, 16 Sep 2005 12:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJO6-0000c4-B4 for ips@megatron.ietf.org; Fri, 16 Sep 2005 12:48:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28497 for ; Fri, 16 Sep 2005 12:48:28 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGJT3-0003NL-CU for ips@ietf.org; Fri, 16 Sep 2005 12:53:45 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8GGmDd7110604 for ; Fri, 16 Sep 2005 16:48:13 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8GGmDdg181468 for ; Fri, 16 Sep 2005 18:48:13 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8GGmDUP019378 for ; Fri, 16 Sep 2005 18:48:13 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8GGmDoF019375; Fri, 16 Sep 2005 18:48:13 +0200 In-Reply-To: <001401c5bacc$aee62420$0a031eac@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Fri, 16 Sep 2005 19:48:10 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 16/09/2005 19:48:12, Serialize complete at 16/09/2005 19:48:12 X-Spam-Score: 0.6 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: ips@ietf.org, "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1944696739==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1944696739== Content-Type: multipart/alternative; boundary="=_alternative 005B4069C225707E_=" This is a multipart message in MIME format. --=_alternative 005B4069C225707E_= Content-Type: text/plain; charset="US-ASCII" The unsolicited data is part of the "unsolicited sequence" (it has to end with the F bit set to one). The immediate part starts always at 0. Al the unsolicited data-PDUs order is governed by the DataPDUinorder. I really don't see the need for any change in text. Julo "Eddy Quicksall" 16-09-05 17:41 To Julian Satran/Haifa/IBM@IBMIL cc , "Mallikarjun C." Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited My point is that the information in parens mentions two things specifically (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). Since there is no "e.g." then this implies that these two things are the ones he is talking about. What I'm saying is that if it were changed to say: (non-immediate unsolicited, R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence) then there would be no ambiguity. Eddy ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ietf.org ; Mallikarjun C. Sent: Friday, September 16, 2005 2:22 AM Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The unsolicited data is always in order (it always start at offset zero). What has to apply? Why should Mallikarjun add the text? What is the question (please reformulate I have trouble understanding your point). Julo "Eddy Quicksall" 16-09-05 02:04 To Julian Satran/Haifa/IBM@IBMIL cc , "Mallikarjun C." Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited I understand that. My question is "does this also apply to non-immediate unsolicited"? I think the answer is yes but I need to get a clarification on that. Perhaps Mallikarjun could change it to (unsolicited and R2T ... ). Eddy ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ietf.org Sent: Thursday, September 15, 2005 2:38 PM Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Eddy, The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering. Ordering within sequence is governed by DataPDUinOrder. Julo "Eddy Quicksall" Sent by: ips-bounces@ietf.org 15-09-05 16:26 To cc Subject [Ips] DataSequenceInOrder for non-immediate unsolicited 12.9 DataSequenceInOrder If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005B4069C225707E_= Content-Type: text/html; charset="US-ASCII"
The unsolicited data is part of the "unsolicited sequence" (it has to end with the F bit set to one). The immediate part starts always at 0.
Al the unsolicited data-PDUs order is governed by the DataPDUinorder. I really don't see the need for any change in text.

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 17:41

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, "Mallikarjun C." <cbm@rose.hp.com>
Subject
Re: [Ips] DataSequenceInOrder for non-immediate unsolicited





My point is that the information in parens mentions two things specifically (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer offset
within a read data sequence). Since there is no "e.g." then this implies that these two things are the ones he is talking about.
 
What I'm saying is that if it were changed to say:
 
(non-immediate unsolicited, R2T
buffer offset for writes, or the smallest SCSI Data-In buffer offset
within a read data sequence)
 
then there would be no ambiguity.
 
Eddy
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ietf.org ; Mallikarjun C.
Sent: Friday, September 16, 2005 2:22 AM
Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited


The unsolicited data is always in order (it always start at offset zero). What has to apply? Why should Mallikarjun add the text? What is the question (please reformulate I have trouble understanding your point).

Julo

"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 02:04


To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, "Mallikarjun C." <cbm@rose.hp.com>
Subject
Re: [Ips] DataSequenceInOrder for non-immediate unsolicited







I understand that. My question is "does this also apply to non-immediate unsolicited"? I think the answer is yes but I need to get a clarification on that.
 
Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).
 
Eddy
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ietf.org
Sent: Thursday, September 15, 2005 2:38 PM
Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited

Eddy,

The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering.
Ordering within sequence is governed by DataPDUinOrder.

Julo
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

15-09-05 16:26


To
<ips@ietf.org>
cc
Subject
[Ips] DataSequenceInOrder for non-immediate unsolicited



12.9 DataSequenceInOrder

 If DataSequenceInOrder is set to Yes, Data Sequences MUST be
transferred using continuously non-decreasing sequence offsets (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer offset
within a read data sequence).

Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation?

Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 005B4069C225707E_=-- --===============1944696739== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1944696739==-- From ips-bounces@ietf.org Fri Sep 16 12:52:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJS0-00019j-Pn; Fri, 16 Sep 2005 12:52:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJRz-00019F-0g for ips@megatron.ietf.org; Fri, 16 Sep 2005 12:52:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28702 for ; Fri, 16 Sep 2005 12:52:31 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGJX0-0003Tp-TP for ips@ietf.org; Fri, 16 Sep 2005 12:57:48 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j8GGqIij016120 for ; Fri, 16 Sep 2005 12:52:18 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j8GGqIje016115; Fri, 16 Sep 2005 12:52:18 -0400 Received: from pkoning.equallogic.com ([172.16.1.181]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Sep 2005 12:52:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17194.63553.322527.276432@gargle.gargle.HOWL> Date: Fri, 16 Sep 2005 12:52:17 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited References: <17194.52844.863000.648829@gargle.gargle.HOWL> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 16 Sep 2005 16:52:18.0646 (UTC) FILETIME=[FFC3DF60:01C5BADE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Julian" == Julian Satran writes: Julian> There is only one unsolicited sequence and it is the first Julian> and starting with 0 makes it ordered always. I am bit tired Julian> about all this gibberish. Never mind, I was thinking about DataPDUInOrder. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 16 12:57:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJWJ-0002fE-9m; Fri, 16 Sep 2005 12:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJWH-0002f6-I3 for ips@megatron.ietf.org; Fri, 16 Sep 2005 12:57:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28964 for ; Fri, 16 Sep 2005 12:56:58 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGJbI-0003cO-Ue for ips@ietf.org; Fri, 16 Sep 2005 13:02:14 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc14) with SMTP id <2005091616564401400oj3ele>; Fri, 16 Sep 2005 16:56:45 +0000 Message-ID: <005101c5badf$9e8c37f0$0a031eac@ivivity.com> From: "Eddy Quicksall" To: , "Julian Satran" References: Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Date: Fri, 16 Sep 2005 12:56:43 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: 2b428fb4265163ba7f2ac2af0ebfcf00 Cc: cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0759616298==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0759616298== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01C5BABE.16AD83F0" This is a multi-part message in MIME format. ------=_NextPart_000_004E_01C5BABE.16AD83F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julian, this is not gibberish. We are in the process of clearing up some = cases for misunderstanding and I believe this is one such case. If you = just remove the parened information then it would not be ambiguous. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: ips@ietf.org=20 Cc: Surekha.PC ; cbm@rose.hp.com ; Eddy Quicksall=20 Sent: Friday, September 16, 2005 12:48 PM Subject: Fw: [Ips] DataSequenceInOrder for non-immediate unsolicited That is not correct. The unsolicited data is a sequence and it has to = be ended before anything else happens. Unsolicited data is equivalent to = a "virtual R2T" with offset 0=20 and R2Ts have to be honored in order.=20 Julo=20 ----- Forwarded by Julian Satran/Haifa/IBM on 16-09-05 19:37 -----=20 "Eddy Quicksall" =20 16-09-05 17:44=20 To "Surekha.PC" , Julian = Satran/Haifa/IBM@IBMIL =20 cc , "'Mallikarjun C.'" =20 Subject Re: [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 The non-immediate unsolicited could be received out of order by the = following events:=20 =20 I-T Command=20 T-I R2T=20 =20 If the initiator receives the R2T before it has begun to send the = non-immediate unsolicited then, if DataSequenceInOrder is no, it could = send the solicited data before sending the non-immediate unsolicited.=20 =20 Eddy=20 ----- Original Message -----=20 From: Surekha.PC=20 To: 'Julian Satran' ; 'Eddy Quicksall'=20 Cc: ips@ietf.org ; 'Mallikarjun C.'=20 Sent: Friday, September 16, 2005 3:10 AM=20 Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited=20 Hi Eddy,=20 =20 I think DataSequenceInOrder "does not apply to non-immediate = unsolicited Data PDUs" since only the first outgoing sequence can be = sent unsolicited, it always starts at offset 0 and is in order as = mentioned by Julian.=20 =20 3.5.1.5 SCSI Data-out and SCSI Data-in=20 An outgoing sequence is either unsolicited (only the first sequence = can be unsolicited) or consists of all the Data-Out PDUs sent in = response to an R2T.=20 So in my opinion the below text rightly says "DataSequenceInOrder = applies only to R2T and SCSI Data in buffer offsets". Hence I think = there is no need for a change.=20 =20 = -------------------------------------------------------------------------= ---------------------------=20 12.9 DataSequenceInOrder=20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 = -------------------------------------------------------------------------= -----------------------------=20 =20 Pls let me know your comments.=20 =20 Thanks,=20 Surekha=20 =20 -------------------------------------------------------------------------= ----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = Julian Satran Sent: Friday, September 16, 2005 11:52 AM To: Eddy Quicksall Cc: ips@ietf.org; Mallikarjun C. Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The unsolicited data is always in order (it always start at offset = zero). What has to apply? Why should Mallikarjun add the text? What is = the question (please reformulate I have trouble understanding your = point).=20 Julo=20 "Eddy Quicksall" =20 16-09-05 02:04=20 =20 To Julian Satran/Haifa/IBM@IBMIL =20 cc , "Mallikarjun C." =20 Subject Re: [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 I understand that. My question is "does this also apply to = non-immediate unsolicited"? I think the answer is yes but I need to get = a clarification on that.=20 =20 Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Thursday, September 15, 2005 2:38 PM=20 Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited=20 Eddy,=20 The unsolicited data start at offset zero. DataSequenceInOrder governs = only the sequence ordering.=20 Ordering within sequence is governed by DataPDUinOrder.=20 Julo "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 15-09-05 16:26=20 =20 To =20 cc =20 Subject [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 12.9 DataSequenceInOrder=20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 Up to the paren, this seems to apply to even non-immediate unsolicited = but there is a slight implication here, by distinctly referencing the = R2T, that this may not apply to non-immediate unsolicited PDUs. What is = the correct interpretation?=20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_004E_01C5BABE.16AD83F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Julian, this=20 is not gibberish. We are in the process of clearing up some cases = for=20 misunderstanding and I believe this is one such case. If you just remove = the=20 parened information then it would not be ambiguous.

 

Eddy

----- Original Message -----
From:=20 Julian Satran
Cc: Surekha.PC ; cbm@rose.hp.com ; Eddy = Quicksall=20
Sent: Friday, September 16, = 2005 12:48=20 PM
Subject: Fw: [Ips] = DataSequenceInOrder=20 for non-immediate unsolicited


That is not = correct. The=20 unsolicited data is a sequence and it has to be ended before anything = else=20 happens. Unsolicited data is equivalent to a "virtual R2T" with offset = 0
and R2Ts have to be = honored in=20 order.

Julo =
----- Forwarded by Julian=20 Satran/Haifa/IBM on 16-09-05 19:37 -----
"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20

16-09-05 17:44

To
"Surekha.PC" <surekhap@cisco.com>,=20 Julian Satran/Haifa/IBM@IBMIL =
cc
<ips@ietf.org>, = "'Mallikarjun=20 C.'" <cbm@rose.hp.com>=20
Subject
Re: [Ips] = DataSequenceInOrder for=20 non-immediate unsolicited

=




The=20 non-immediate unsolicited could be received out of order by the = following=20 events:
 
I-T = Command
T-I R2T
 =20
If the initiator receives the R2T before it has = begun to send=20 the non-immediate unsolicited then, if DataSequenceInOrder is no, it = could=20 send the solicited data before sending the non-immediate = unsolicited.=20
 
Eddy =
----- Original Message -----
From:=20 Surekha.PC
To: 'Julian Satran' = ; 'Eddy Quicksall' =
Cc: ips@ietf.org ; 'Mallikarjun=20 C.'
Sent: Friday,=20 September 16, 2005 3:10 AM
Subject: = RE: [Ips]=20 DataSequenceInOrder for non-immediate unsolicited

Hi Eddy,
 =20
I think = DataSequenceInOrder "does not=20 apply to non-immediate unsolicited Data PDUs" since only the first = outgoing=20 sequence can be sent unsolicited, it always starts at offset 0 and is = in order=20 as mentioned by Julian.
  =
3.5.1.5 SCSI Data-out and SCSI = Data-in=20
An outgoing sequence is = either=20 unsolicited (only the first sequence can be unsolicited) or = consists of=20 all the Data-Out PDUs sent in response to an R2T.
So in my opinion the below text rightly says=20 "DataSequenceInOrder applies only to R2T and SCSI Data in buffer = offsets".=20 Hence I think there is no need for a change.
 
----------------------------------------------------------------= ------------------------------------=20
12.9 DataSequenceInOrder =

 If DataSequenceInOrder is set to Yes, Data = Sequences MUST=20 be
transferred using continuously non-decreasing sequence offsets=20 (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer=20 offset
within a read data sequence). =
----------------------------------------------------------------= --------------------------------------=20
 
Pls let=20 me know your comments.
  =
Thanks,
Surekha
 
From: ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of Julian=20 Satran
Sent: Friday, September 16, 2005 11:52 = AM
To: Eddy=20 Quicksall
Cc: ips@ietf.org; Mallikarjun = C.
Subject: Re:=20 [Ips] DataSequenceInOrder for non-immediate unsolicited


The = unsolicited data is=20 always in order (it always start at offset zero). What has to apply? = Why=20 should Mallikarjun add the text? What is the question (please = reformulate I=20 have trouble understanding your point). =

Julo =

"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 02:04=20


To
Julian=20 Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>,=20 "Mallikarjun C." <cbm@rose.hp.com>=20
Subject
Re: [Ips] = DataSequenceInOrder for=20 non-immediate = unsolicited







I understand that. My = question is "does=20 this also apply to non-immediate unsolicited"? I think the answer is = yes but I=20 need to get a clarification on that.=20
 
Perhaps Mallikarjun could change = it to=20 (unsolicited and R2T ... ). =
 
Eddy
----- Original Message = -----=20
From: Julian Satran =
To:=20 Eddy Quicksall =
Cc:=20 ips@ietf.org =
Sent: Thursday,=20 September 15, 2005 2:38 PM
Subject: Re: [Ips] = DataSequenceInOrder=20 for non-immediate unsolicited

Eddy,

The unsolicited data start at offset zero. = DataSequenceInOrder=20 governs only the sequence ordering.
Ordering within sequence is governed by = DataPDUinOrder.

Julo
"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org =

15-09-05 16:26=20


To
<ips@ietf.org>
cc
Subject
[Ips] = DataSequenceInOrder for=20 non-immediate = unsolicited






12.9 DataSequenceInOrder =

 If DataSequenceInOrder is set to Yes, Data = Sequences MUST=20 be
transferred using continuously non-decreasing sequence offsets=20 (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer=20 offset
within a read data sequence). =

Up to the paren, this seems to apply to even = non-immediate=20 unsolicited but there is a slight implication here, by distinctly = referencing=20 the R2T, that this may not apply to non-immediate unsolicited PDUs. = What is=20 the correct interpretation?

Eddy_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips= =20

_______________________________________________
Ips mailing=20 list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips =

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

------=_NextPart_000_004E_01C5BABE.16AD83F0-- --===============0759616298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0759616298==-- From ips-bounces@ietf.org Fri Sep 16 13:04:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJds-0004X8-Ce; Fri, 16 Sep 2005 13:04:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJdq-0004U9-Gs for ips@megatron.ietf.org; Fri, 16 Sep 2005 13:04:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29422 for ; Fri, 16 Sep 2005 13:04:46 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGJiq-0003r6-Hv for ips@ietf.org; Fri, 16 Sep 2005 13:10:03 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc13) with SMTP id <2005091617043601500o2p4ne>; Fri, 16 Sep 2005 17:04:37 +0000 Message-ID: <007f01c5bae0$b800fbc0$0a031eac@ivivity.com> From: "Eddy Quicksall" To: , "Julian Satran" References: Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Date: Fri, 16 Sep 2005 13:04:36 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: c96e11e58076fc8e92061fb6cbdfae15 Cc: cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0913007858==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0913007858== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C5BABF.3037A480" This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C5BABF.3037A480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From RFC 3720 3.2.4.2: "on each connection . command N+1 MAY be sent = before the unsolicited Data-Out PDUs for command N, but the unsolicited = Data-out PDUs for command N MUST precede the unsolicited Data-Out PDUs = of command N+1." Is this what you are referring to? If so it doesn't say what you have = stated below. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: ips@ietf.org=20 Cc: Surekha.PC ; cbm@rose.hp.com ; Eddy Quicksall=20 Sent: Friday, September 16, 2005 12:48 PM Subject: Fw: [Ips] DataSequenceInOrder for non-immediate unsolicited That is not correct. The unsolicited data is a sequence and it has to = be ended before anything else happens. Unsolicited data is equivalent to = a "virtual R2T" with offset 0=20 and R2Ts have to be honored in order.=20 Julo=20 ----- Forwarded by Julian Satran/Haifa/IBM on 16-09-05 19:37 -----=20 "Eddy Quicksall" =20 16-09-05 17:44=20 To "Surekha.PC" , Julian = Satran/Haifa/IBM@IBMIL =20 cc , "'Mallikarjun C.'" =20 Subject Re: [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 The non-immediate unsolicited could be received out of order by the = following events:=20 =20 I-T Command=20 T-I R2T=20 =20 If the initiator receives the R2T before it has begun to send the = non-immediate unsolicited then, if DataSequenceInOrder is no, it could = send the solicited data before sending the non-immediate unsolicited.=20 =20 Eddy=20 ----- Original Message -----=20 From: Surekha.PC=20 To: 'Julian Satran' ; 'Eddy Quicksall'=20 Cc: ips@ietf.org ; 'Mallikarjun C.'=20 Sent: Friday, September 16, 2005 3:10 AM=20 Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited=20 Hi Eddy,=20 =20 I think DataSequenceInOrder "does not apply to non-immediate = unsolicited Data PDUs" since only the first outgoing sequence can be = sent unsolicited, it always starts at offset 0 and is in order as = mentioned by Julian.=20 =20 3.5.1.5 SCSI Data-out and SCSI Data-in=20 An outgoing sequence is either unsolicited (only the first sequence = can be unsolicited) or consists of all the Data-Out PDUs sent in = response to an R2T.=20 So in my opinion the below text rightly says "DataSequenceInOrder = applies only to R2T and SCSI Data in buffer offsets". Hence I think = there is no need for a change.=20 =20 = -------------------------------------------------------------------------= ---------------------------=20 12.9 DataSequenceInOrder=20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 = -------------------------------------------------------------------------= -----------------------------=20 =20 Pls let me know your comments.=20 =20 Thanks,=20 Surekha=20 =20 -------------------------------------------------------------------------= ----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = Julian Satran Sent: Friday, September 16, 2005 11:52 AM To: Eddy Quicksall Cc: ips@ietf.org; Mallikarjun C. Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The unsolicited data is always in order (it always start at offset = zero). What has to apply? Why should Mallikarjun add the text? What is = the question (please reformulate I have trouble understanding your = point).=20 Julo=20 "Eddy Quicksall" =20 16-09-05 02:04=20 =20 To Julian Satran/Haifa/IBM@IBMIL =20 cc , "Mallikarjun C." =20 Subject Re: [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 I understand that. My question is "does this also apply to = non-immediate unsolicited"? I think the answer is yes but I need to get = a clarification on that.=20 =20 Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Thursday, September 15, 2005 2:38 PM=20 Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited=20 Eddy,=20 The unsolicited data start at offset zero. DataSequenceInOrder governs = only the sequence ordering.=20 Ordering within sequence is governed by DataPDUinOrder.=20 Julo "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 15-09-05 16:26=20 =20 To =20 cc =20 Subject [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 12.9 DataSequenceInOrder=20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 Up to the paren, this seems to apply to even non-immediate unsolicited = but there is a slight implication here, by distinctly referencing the = R2T, that this may not apply to non-immediate unsolicited PDUs. What is = the correct interpretation?=20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_007C_01C5BABF.3037A480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From RFC 3720 = 3.2.4.2: =93on each=20 connection =85 command N+1 MAY be sent before the unsolicited Data-Out = PDUs for=20 command N, but the unsolicited Data-out PDUs for command N MUST precede = the=20 unsolicited Data-Out PDUs of command N+1.=94

 

Is this=20 what you are referring to? If so it doesn't say what you have stated=20 below.

 

Eddy

----- Original Message -----
From:=20 Julian Satran
Cc: Surekha.PC ; cbm@rose.hp.com ; Eddy = Quicksall=20
Sent: Friday, September 16, = 2005 12:48=20 PM
Subject: Fw: [Ips] = DataSequenceInOrder=20 for non-immediate unsolicited


That is not = correct. The=20 unsolicited data is a sequence and it has to be ended before anything = else=20 happens. Unsolicited data is equivalent to a "virtual R2T" with offset = 0
and R2Ts have to be = honored in=20 order.

Julo =
----- Forwarded by Julian=20 Satran/Haifa/IBM on 16-09-05 19:37 -----
"Eddy = Quicksall" <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20

16-09-05 17:44

To
"Surekha.PC" <surekhap@cisco.com>,=20 Julian Satran/Haifa/IBM@IBMIL =
cc
<ips@ietf.org>, = "'Mallikarjun=20 C.'" <cbm@rose.hp.com>=20
Subject
Re: [Ips] = DataSequenceInOrder for=20 non-immediate unsolicited

=




The=20 non-immediate unsolicited could be received out of order by the = following=20 events:
 
I-T = Command
T-I R2T
 =20
If the initiator receives the R2T before it has = begun to send=20 the non-immediate unsolicited then, if DataSequenceInOrder is no, it = could=20 send the solicited data before sending the non-immediate = unsolicited.=20
 
Eddy =
----- Original Message -----
From:=20 Surekha.PC
To: 'Julian Satran' = ; 'Eddy Quicksall' =
Cc: ips@ietf.org ; 'Mallikarjun=20 C.'
Sent: Friday,=20 September 16, 2005 3:10 AM
Subject: = RE: [Ips]=20 DataSequenceInOrder for non-immediate unsolicited

Hi Eddy,
 =20
I think = DataSequenceInOrder "does not=20 apply to non-immediate unsolicited Data PDUs" since only the first = outgoing=20 sequence can be sent unsolicited, it always starts at offset 0 and is = in order=20 as mentioned by Julian.
  =
3.5.1.5 SCSI Data-out and SCSI = Data-in=20
An outgoing sequence is = either=20 unsolicited (only the first sequence can be unsolicited) or = consists of=20 all the Data-Out PDUs sent in response to an R2T.
So in my opinion the below text rightly says=20 "DataSequenceInOrder applies only to R2T and SCSI Data in buffer = offsets".=20 Hence I think there is no need for a change.
 
----------------------------------------------------------------= ------------------------------------=20
12.9 DataSequenceInOrder =

 If DataSequenceInOrder is set to Yes, Data = Sequences MUST=20 be
transferred using continuously non-decreasing sequence offsets=20 (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer=20 offset
within a read data sequence). =
----------------------------------------------------------------= --------------------------------------=20
 
Pls let=20 me know your comments.
  =
Thanks,
Surekha
 
From: ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of Julian=20 Satran
Sent: Friday, September 16, 2005 11:52 = AM
To: Eddy=20 Quicksall
Cc: ips@ietf.org; Mallikarjun = C.
Subject: Re:=20 [Ips] DataSequenceInOrder for non-immediate unsolicited


The = unsolicited data is=20 always in order (it always start at offset zero). What has to apply? = Why=20 should Mallikarjun add the text? What is the question (please = reformulate I=20 have trouble understanding your point). =

Julo =

"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 02:04=20


To
Julian=20 Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>,=20 "Mallikarjun C." <cbm@rose.hp.com>=20
Subject
Re: [Ips] = DataSequenceInOrder for=20 non-immediate = unsolicited







I understand that. My = question is "does=20 this also apply to non-immediate unsolicited"? I think the answer is = yes but I=20 need to get a clarification on that.=20
 
Perhaps Mallikarjun could change = it to=20 (unsolicited and R2T ... ). =
 
Eddy
----- Original Message = -----=20
From: Julian Satran =
To:=20 Eddy Quicksall =
Cc:=20 ips@ietf.org =
Sent: Thursday,=20 September 15, 2005 2:38 PM
Subject: Re: [Ips] = DataSequenceInOrder=20 for non-immediate unsolicited

Eddy,

The unsolicited data start at offset zero. = DataSequenceInOrder=20 governs only the sequence ordering.
Ordering within sequence is governed by = DataPDUinOrder.

Julo
"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org =

15-09-05 16:26=20


To
<ips@ietf.org>
cc
Subject
[Ips] = DataSequenceInOrder for=20 non-immediate = unsolicited






12.9 DataSequenceInOrder =

 If DataSequenceInOrder is set to Yes, Data = Sequences MUST=20 be
transferred using continuously non-decreasing sequence offsets=20 (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer=20 offset
within a read data sequence). =

Up to the paren, this seems to apply to even = non-immediate=20 unsolicited but there is a slight implication here, by distinctly = referencing=20 the R2T, that this may not apply to non-immediate unsolicited PDUs. = What is=20 the correct interpretation?

Eddy_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips= =20

_______________________________________________
Ips mailing=20 list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips =

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

------=_NextPart_000_007C_01C5BABF.3037A480-- --===============0913007858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0913007858==-- From ips-bounces@ietf.org Fri Sep 16 13:18:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJqz-0007mh-Up; Fri, 16 Sep 2005 13:18:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGJqx-0007mY-RU for ips@megatron.ietf.org; Fri, 16 Sep 2005 13:18:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29949 for ; Fri, 16 Sep 2005 13:18:20 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGJw0-0004BO-3Q for ips@ietf.org; Fri, 16 Sep 2005 13:23:36 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc14) with SMTP id <2005091617181101400olncue>; Fri, 16 Sep 2005 17:18:11 +0000 Message-ID: <009c01c5bae2$9db3d1f0$0a031eac@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: <007f01c5bae0$b800fbc0$0a031eac@ivivity.com> Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Date: Fri, 16 Sep 2005 13:18:11 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: 6217cd54077d488d29096a65a152105e Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1109778999==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1109778999== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01C5BAC1.1610A050" This is a multi-part message in MIME format. ------=_NextPart_000_0099_01C5BAC1.1610A050 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'll accept that this may just be due to the way I read English and if = others agree that the paren'd text does not exclude non-immediate = unsolicited then just let me know that and I'll accept it. Eddy ----- Original Message -----=20 From: Eddy Quicksall=20 To: ips@ietf.org ; Julian Satran=20 Cc: cbm@rose.hp.com=20 Sent: Friday, September 16, 2005 1:04 PM Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited From RFC 3720 3.2.4.2: "on each connection . command N+1 MAY be sent = before the unsolicited Data-Out PDUs for command N, but the unsolicited = Data-out PDUs for command N MUST precede the unsolicited Data-Out PDUs = of command N+1." Is this what you are referring to? If so it doesn't say what you have = stated below. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: ips@ietf.org=20 Cc: Surekha.PC ; cbm@rose.hp.com ; Eddy Quicksall=20 Sent: Friday, September 16, 2005 12:48 PM Subject: Fw: [Ips] DataSequenceInOrder for non-immediate unsolicited That is not correct. The unsolicited data is a sequence and it has = to be ended before anything else happens. Unsolicited data is equivalent = to a "virtual R2T" with offset 0=20 and R2Ts have to be honored in order.=20 Julo=20 ----- Forwarded by Julian Satran/Haifa/IBM on 16-09-05 19:37 -----=20 "Eddy Quicksall" =20 16-09-05 17:44=20 To "Surekha.PC" , Julian = Satran/Haifa/IBM@IBMIL =20 cc , "'Mallikarjun C.'" = Subject Re: [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 The non-immediate unsolicited could be received out of order by the = following events:=20 =20 I-T Command=20 T-I R2T=20 =20 If the initiator receives the R2T before it has begun to send the = non-immediate unsolicited then, if DataSequenceInOrder is no, it could = send the solicited data before sending the non-immediate unsolicited.=20 =20 Eddy=20 ----- Original Message -----=20 From: Surekha.PC=20 To: 'Julian Satran' ; 'Eddy Quicksall'=20 Cc: ips@ietf.org ; 'Mallikarjun C.'=20 Sent: Friday, September 16, 2005 3:10 AM=20 Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited = Hi Eddy,=20 =20 I think DataSequenceInOrder "does not apply to non-immediate = unsolicited Data PDUs" since only the first outgoing sequence can be = sent unsolicited, it always starts at offset 0 and is in order as = mentioned by Julian.=20 =20 3.5.1.5 SCSI Data-out and SCSI Data-in=20 An outgoing sequence is either unsolicited (only the first sequence = can be unsolicited) or consists of all the Data-Out PDUs sent in = response to an R2T.=20 So in my opinion the below text rightly says "DataSequenceInOrder = applies only to R2T and SCSI Data in buffer offsets". Hence I think = there is no need for a change.=20 =20 = -------------------------------------------------------------------------= ---------------------------=20 12.9 DataSequenceInOrder=20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 = -------------------------------------------------------------------------= -----------------------------=20 =20 Pls let me know your comments.=20 =20 Thanks,=20 Surekha=20 =20 -------------------------------------------------------------------------= --- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf = Of Julian Satran Sent: Friday, September 16, 2005 11:52 AM To: Eddy Quicksall Cc: ips@ietf.org; Mallikarjun C. Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The unsolicited data is always in order (it always start at offset = zero). What has to apply? Why should Mallikarjun add the text? What is = the question (please reformulate I have trouble understanding your = point).=20 Julo=20 "Eddy Quicksall" =20 16-09-05 02:04=20 =20 To Julian Satran/Haifa/IBM@IBMIL =20 cc , "Mallikarjun C." =20 Subject Re: [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 I understand that. My question is "does this also apply to = non-immediate unsolicited"? I think the answer is yes but I need to get = a clarification on that.=20 =20 Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Thursday, September 15, 2005 2:38 PM=20 Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited = Eddy,=20 The unsolicited data start at offset zero. DataSequenceInOrder = governs only the sequence ordering.=20 Ordering within sequence is governed by DataPDUinOrder.=20 Julo "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 15-09-05 16:26=20 =20 To =20 cc =20 Subject [Ips] DataSequenceInOrder for non-immediate = unsolicited=20 =20 =20 12.9 DataSequenceInOrder=20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 Up to the paren, this seems to apply to even non-immediate = unsolicited but there is a slight implication here, by distinctly = referencing the R2T, that this may not apply to non-immediate = unsolicited PDUs. What is the correct interpretation?=20 Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= --- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 -------------------------------------------------------------------------= --- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0099_01C5BAC1.1610A050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'll accept that this may just be due to the way I = read=20 English and if others agree that the paren'd text does not exclude = non-immediate=20 unsolicited then just let me know that and I'll accept it.
 
Eddy
----- Original Message -----
From:=20 Eddy = Quicksall=20
To: ips@ietf.org ; Julian=20 Satran
Sent: Friday, September 16, = 2005 1:04=20 PM
Subject: Re: [Ips] = DataSequenceInOrder=20 for non-immediate unsolicited

From RFC 3720 = 3.2.4.2: =93on each=20 connection =85 command N+1 MAY be sent before the unsolicited Data-Out = PDUs for=20 command N, but the unsolicited Data-out PDUs for command N MUST = precede the=20 unsolicited Data-Out PDUs of command N+1.=94

 

Is this=20 what you are referring to? If so it doesn't say what you have stated=20 below.

 

Eddy

----- Original Message -----
From:=20 Julian Satran
Cc: Surekha.PC ; cbm@rose.hp.com ; Eddy = Quicksall=20
Sent: Friday, September 16, = 2005 12:48=20 PM
Subject: Fw: [Ips] = DataSequenceInOrder=20 for non-immediate unsolicited


That is not = correct. The=20 unsolicited data is a sequence and it has to be ended before = anything else=20 happens. Unsolicited data is equivalent to a "virtual R2T" with = offset=20 0
and R2Ts have to be = honored in=20 order.

Julo =
----- Forwarded by Julian = Satran/Haifa/IBM on 16-09-05 19:37 -----
"Eddy = Quicksall"=20 <eddy_quicksall_i= Vivity_iSCSI@comcast.net>=20

16-09-05 17:44

To
"Surekha.PC" <surekhap@cisco.com>,=20 Julian Satran/Haifa/IBM@IBMIL =
cc
<ips@ietf.org>, = "'Mallikarjun=20 C.'" <cbm@rose.hp.com>=20
Subject
Re: [Ips] = DataSequenceInOrder=20 for non-immediate = unsolicited

=




<= FONT=20 size=3D2>The non-immediate unsolicited could be received out of = order by the=20 following events:
 
I-T=20 Command
T-I R2T
 
If the initiator receives = the R2T=20 before it has begun to send the non-immediate unsolicited then, if=20 DataSequenceInOrder is no, it could send the solicited data before = sending=20 the non-immediate unsolicited.
 =20
Eddy
----- Original = Message -----=20
From: Surekha.PC =
To: 'Julian Satran' ; 'Eddy Quicksall' =
Cc: ips@ietf.org ; 'Mallikarjun=20 C.'
Sent: Friday,=20 September 16, 2005 3:10 AM
Subject: = RE: [Ips]=20 DataSequenceInOrder for non-immediate unsolicited =

Hi Eddy,
 =20
I think = DataSequenceInOrder "does not=20 apply to non-immediate unsolicited Data PDUs" since only the first = outgoing=20 sequence can be sent unsolicited, it always starts at offset 0 and = is in=20 order as mentioned by Julian.
 =20
3.5.1.5 SCSI Data-out = and SCSI=20 Data-in
An = outgoing sequence=20 is either unsolicited (only the first sequence can be = unsolicited) or=20 consists of all the Data-Out PDUs sent in response to an R2T. =
So in my opinion the = below text=20 rightly says "DataSequenceInOrder applies only to R2T and SCSI Data = in=20 buffer offsets". Hence I think there is no need for a change. =
 
----------------------------------------------------------------= ------------------------------------=20
12.9 DataSequenceInOrder=20

 If DataSequenceInOrder is set to = Yes, Data=20 Sequences MUST be
transferred using continuously non-decreasing = sequence=20 offsets (R2T
buffer offset for writes, or the smallest SCSI = Data-In=20 buffer offset
within a read data sequence). =
----------------------------------------------------------------= --------------------------------------=20
 
Pls=20 let me know your comments.
  =
Thanks,
Surekha
 
From: ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of Julian=20 Satran
Sent: Friday, September 16, 2005 11:52 = AM
To:=20 Eddy Quicksall
Cc: ips@ietf.org; Mallikarjun = C.
Subject:=20 Re: [Ips] DataSequenceInOrder for non-immediate = unsolicited


The = unsolicited data=20 is always in order (it always start at offset zero). What has to = apply? Why=20 should Mallikarjun add the text? What is the question (please = reformulate I=20 have trouble understanding your point). =

Julo =

"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 02:04=20


To
Julian=20 Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, = "Mallikarjun C." <cbm@rose.hp.com>=20
Subject
Re: [Ips] = DataSequenceInOrder=20 for non-immediate = unsolicited






I understand that. My = question is=20 "does this also apply to non-immediate unsolicited"? I think the = answer is=20 yes but I need to get a clarification on that. =
 
Perhaps Mallikarjun could change = it to=20 (unsolicited and R2T ... ). =
 
Eddy
----- Original Message = -----=20
From: Julian Satran =
To: Eddy Quicksall =
Cc:=20 ips@ietf.org =
Sent:=20 Thursday, September 15, 2005 2:38 PM
Subject: Re: [Ips]=20 DataSequenceInOrder for non-immediate unsolicited

Eddy, =

The unsolicited data start at = offset zero.=20 DataSequenceInOrder governs only the sequence ordering.=20
Ordering within sequence = is governed=20 by DataPDUinOrder.

Julo
"Eddy = Quicksall"=20 <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org =

15-09-05 16:26=20


To
<ips@ietf.org>
cc
Subject
[Ips] = DataSequenceInOrder for=20 non-immediate = unsolicited





12.9 DataSequenceInOrder =

 If DataSequenceInOrder is set to Yes, Data = Sequences MUST=20 be
transferred using continuously non-decreasing sequence offsets = (R2T
buffer offset for writes, or the smallest SCSI Data-In = buffer=20 offset
within a read data sequence). =

Up to the paren, this seems to apply to even = non-immediate=20 unsolicited but there is a slight implication here, by distinctly=20 referencing the R2T, that this may not apply to non-immediate = unsolicited=20 PDUs. What is the correct interpretation?=20

Eddy_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips= =20

_______________________________________________
Ips=20 mailing = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=20

_______________________________________________
Ips=20 mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips=

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0099_01C5BAC1.1610A050-- --===============1109778999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1109778999==-- From ips-bounces@ietf.org Fri Sep 16 14:56:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLOF-0007M7-4w; Fri, 16 Sep 2005 14:56:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLOC-0007LS-Ca for ips@megatron.ietf.org; Fri, 16 Sep 2005 14:56:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04043 for ; Fri, 16 Sep 2005 14:56:46 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGLTF-0006Rj-DI for ips@ietf.org; Fri, 16 Sep 2005 15:02:02 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8GIubd7161476 for ; Fri, 16 Sep 2005 18:56:37 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8GIubdg119110 for ; Fri, 16 Sep 2005 20:56:37 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8GIub03004599 for ; Fri, 16 Sep 2005 20:56:37 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8GIuapb004596; Fri, 16 Sep 2005 20:56:36 +0200 In-Reply-To: <005101c5badf$9e8c37f0$0a031eac@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Fri, 16 Sep 2005 21:56:34 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 16/09/2005 21:56:36, Serialize complete at 16/09/2005 21:56:36 X-Spam-Score: 0.6 (/) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 Cc: ips@ietf.org, cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0544200937==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0544200937== Content-Type: multipart/alternative; boundary="=_alternative 006242FDC225707E_=" This is a multipart message in MIME format. --=_alternative 006242FDC225707E_= Content-Type: text/plain; charset="US-ASCII" Eddy, There is no ambiguity IMHO. Julo "Eddy Quicksall" 16-09-05 19:56 To , Julian Satran/Haifa/IBM@IBMIL cc "Surekha.PC" , Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Julian, this is not gibberish. We are in the process of clearing up some cases for misunderstanding and I believe this is one such case. If you just remove the parened information then it would not be ambiguous. Eddy ----- Original Message ----- From: Julian Satran To: ips@ietf.org Cc: Surekha.PC ; cbm@rose.hp.com ; Eddy Quicksall Sent: Friday, September 16, 2005 12:48 PM Subject: Fw: [Ips] DataSequenceInOrder for non-immediate unsolicited That is not correct. The unsolicited data is a sequence and it has to be ended before anything else happens. Unsolicited data is equivalent to a "virtual R2T" with offset 0 and R2Ts have to be honored in order. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 16-09-05 19:37 ----- "Eddy Quicksall" 16-09-05 17:44 To "Surekha.PC" , Julian Satran/Haifa/IBM@IBMIL cc , "'Mallikarjun C.'" Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The non-immediate unsolicited could be received out of order by the following events: I-T Command T-I R2T If the initiator receives the R2T before it has begun to send the non-immediate unsolicited then, if DataSequenceInOrder is no, it could send the solicited data before sending the non-immediate unsolicited. Eddy ----- Original Message ----- From: Surekha.PC To: 'Julian Satran' ; 'Eddy Quicksall' Cc: ips@ietf.org ; 'Mallikarjun C.' Sent: Friday, September 16, 2005 3:10 AM Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited Hi Eddy, I think DataSequenceInOrder "does not apply to non-immediate unsolicited Data PDUs" since only the first outgoing sequence can be sent unsolicited, it always starts at offset 0 and is in order as mentioned by Julian. 3.5.1.5 SCSI Data-out and SCSI Data-in An outgoing sequence is either unsolicited (only the first sequence can be unsolicited) or consists of all the Data-Out PDUs sent in response to an R2T. So in my opinion the below text rightly says "DataSequenceInOrder applies only to R2T and SCSI Data in buffer offsets". Hence I think there is no need for a change. ---------------------------------------------------------------------------------------------------- 12.9 DataSequenceInOrder If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). ------------------------------------------------------------------------------------------------------ Pls let me know your comments. Thanks, Surekha From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran Sent: Friday, September 16, 2005 11:52 AM To: Eddy Quicksall Cc: ips@ietf.org; Mallikarjun C. Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The unsolicited data is always in order (it always start at offset zero). What has to apply? Why should Mallikarjun add the text? What is the question (please reformulate I have trouble understanding your point). Julo "Eddy Quicksall" 16-09-05 02:04 To Julian Satran/Haifa/IBM@IBMIL cc , "Mallikarjun C." Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited I understand that. My question is "does this also apply to non-immediate unsolicited"? I think the answer is yes but I need to get a clarification on that. Perhaps Mallikarjun could change it to (unsolicited and R2T ... ). Eddy ----- Original Message ----- From: Julian Satran To: Eddy Quicksall Cc: ips@ietf.org Sent: Thursday, September 15, 2005 2:38 PM Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited Eddy, The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering. Ordering within sequence is governed by DataPDUinOrder. Julo "Eddy Quicksall" Sent by: ips-bounces@ietf.org 15-09-05 16:26 To cc Subject [Ips] DataSequenceInOrder for non-immediate unsolicited 12.9 DataSequenceInOrder If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence). Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 006242FDC225707E_= Content-Type: text/html; charset="US-ASCII"
Eddy,

There is no ambiguity IMHO.

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 19:56

To
<ips@ietf.org>, Julian Satran/Haifa/IBM@IBMIL
cc
"Surekha.PC" <surekhap@cisco.com>, <cbm@rose.hp.com>
Subject
Re: [Ips] DataSequenceInOrder for non-immediate unsolicited





Julian, this is not gibberish. We are in the process of clearing up some cases for misunderstanding and I believe this is one such case. If you just remove the parened information then it would not be ambiguous.
 
Eddy

----- Original Message -----
From: Julian Satran
To: ips@ietf.org
Cc: Surekha.PC ; cbm@rose.hp.com ; Eddy Quicksall
Sent: Friday, September 16, 2005 12:48 PM
Subject: Fw: [Ips] DataSequenceInOrder for non-immediate unsolicited


That is not correct. The unsolicited data is a sequence and it has to be ended before anything else happens. Unsolicited data is equivalent to a "virtual R2T" with offset 0
and R2Ts have to be honored in order.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 16-09-05 19:37 -----
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 17:44


To
"Surekha.PC" <surekhap@cisco.com>, Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, "'Mallikarjun C.'" <cbm@rose.hp.com>
Subject
Re: [Ips] DataSequenceInOrder for non-immediate unsolicited







The non-immediate unsolicited could be received out of order by the following events:
 
I-T Command
T-I R2T
 
If the initiator receives the R2T before it has begun to send the non-immediate unsolicited then, if DataSequenceInOrder is no, it could send the solicited data before sending the non-immediate unsolicited.
 
Eddy
----- Original Message -----
From: Surekha.PC
To: 'Julian Satran' ; 'Eddy Quicksall'
Cc: ips@ietf.org ; 'Mallikarjun C.'
Sent: Friday, September 16, 2005 3:10 AM
Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited

Hi Eddy,
 
I think DataSequenceInOrder "does not apply to non-immediate unsolicited Data PDUs" since only the first outgoing sequence can be sent unsolicited, it always starts at offset 0 and is in order as mentioned by Julian.
 
3.5.1.5 SCSI Data-out and SCSI Data-in
An outgoing sequence is either unsolicited (only the first sequence can be unsolicited) or consists of all the Data-Out PDUs sent in response to an R2T.
So in my opinion the below text rightly says "DataSequenceInOrder applies only to R2T and SCSI Data in buffer offsets". Hence I think there is no need for a change.
 
----------------------------------------------------------------------------------------------------
12.9 DataSequenceInOrder

If DataSequenceInOrder is set to Yes, Data Sequences MUST be
transferred using continuously non-decreasing sequence offsets (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer offset
within a read data sequence).
------------------------------------------------------------------------------------------------------
 
Pls let me know your comments.
 
Thanks,
Surekha
 

From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran
Sent: Friday, September 16, 2005 11:52 AM
To: Eddy Quicksall
Cc: ips@ietf.org; Mallikarjun C.
Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited


The unsolicited data is always in order (it always start at offset zero). What has to apply? Why should Mallikarjun add the text? What is the question (please reformulate I have trouble understanding your point).

Julo
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

16-09-05 02:04


To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, "Mallikarjun C." <cbm@rose.hp.com>
Subject
Re: [Ips] DataSequenceInOrder for non-immediate unsolicited






I understand that. My question is "does this also apply to non-immediate unsolicited"? I think the answer is yes but I need to get a clarification on that.

Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).

Eddy
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ietf.org
Sent: Thursday, September 15, 2005 2:38 PM
Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited

Eddy,

The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering.
Ordering within sequence is governed by DataPDUinOrder.

Julo
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

15-09-05 16:26


To
<ips@ietf.org>
cc
Subject
[Ips] DataSequenceInOrder for non-immediate unsolicited




12.9 DataSequenceInOrder

If DataSequenceInOrder is set to Yes, Data Sequences MUST be
transferred using continuously non-decreasing sequence offsets (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer offset
within a read data sequence).

Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation?

Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 006242FDC225707E_=-- --===============0544200937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0544200937==-- From ips-bounces@ietf.org Fri Sep 16 14:56:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLOJ-0007Mm-AM; Fri, 16 Sep 2005 14:56:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLOH-0007Mh-JF for ips@megatron.ietf.org; Fri, 16 Sep 2005 14:56:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04052 for ; Fri, 16 Sep 2005 14:56:51 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGLTK-0006Rk-Da for ips@ietf.org; Fri, 16 Sep 2005 15:02:07 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8GIucTZ194482 for ; Fri, 16 Sep 2005 18:56:38 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8GIucdg119118 for ; Fri, 16 Sep 2005 20:56:38 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8GIucef004279 for ; Fri, 16 Sep 2005 20:56:38 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8GIucKa004276; Fri, 16 Sep 2005 20:56:38 +0200 In-Reply-To: <007f01c5bae0$b800fbc0$0a031eac@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Fri, 16 Sep 2005 21:56:34 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 16/09/2005 21:56:37, Serialize complete at 16/09/2005 21:56:37 X-Spam-Score: 0.6 (/) X-Scan-Signature: 7ddf3da2e36bf1816c08a54f16fcec30 Cc: ips@ietf.org, cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1339002533==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1339002533== Content-Type: multipart/alternative; boundary="=_alternative 0062842AC225707E_=" This is a multipart message in MIME format. --=_alternative 0062842AC225707E_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable There is another paragraph that specifies that R2Ts must be served in the=20 order they where received and the "virtual one" is the first. Julo "Eddy Quicksall" =20 16-09-05 20:04 To , Julian Satran/Haifa/IBM@IBMIL cc "Surekha.PC" , Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited >From RFC 3720 3.2.4.2: ?on each connection ? command N+1 MAY be sent=20 before the unsolicited Data-Out PDUs for command N, but the unsolicited=20 Data-out PDUs for command N MUST precede the unsolicited Data-Out PDUs of=20 command N+1.? =20 Is this what you are referring to? If so it doesn't say what you have=20 stated below. =20 Eddy ----- Original Message -----=20 From: Julian Satran=20 To: ips@ietf.org=20 Cc: Surekha.PC ; cbm@rose.hp.com ; Eddy Quicksall=20 Sent: Friday, September 16, 2005 12:48 PM Subject: Fw: [Ips] DataSequenceInOrder for non-immediate unsolicited That is not correct. The unsolicited data is a sequence and it has to be=20 ended before anything else happens. Unsolicited data is equivalent to a=20 "virtual R2T" with offset 0=20 and R2Ts have to be honored in order.=20 Julo=20 ----- Forwarded by Julian Satran/Haifa/IBM on 16-09-05 19:37 -----=20 "Eddy Quicksall" =20 16-09-05 17:44=20 To "Surekha.PC" , Julian Satran/Haifa/IBM@IBMIL=20 cc , "'Mallikarjun C.'" =20 Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The non-immediate unsolicited could be received out of order by the=20 following events:=20 =20 I-T Command=20 T-I R2T=20 =20 If the initiator receives the R2T before it has begun to send the=20 non-immediate unsolicited then, if DataSequenceInOrder is no, it could=20 send the solicited data before sending the non-immediate unsolicited.=20 =20 Eddy=20 ----- Original Message -----=20 From: Surekha.PC=20 To: 'Julian Satran' ; 'Eddy Quicksall'=20 Cc: ips@ietf.org ; 'Mallikarjun C.'=20 Sent: Friday, September 16, 2005 3:10 AM=20 Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited=20 Hi Eddy,=20 =20 I think DataSequenceInOrder "does not apply to non-immediate unsolicited=20 Data PDUs" since only the first outgoing sequence can be sent unsolicited, = it always starts at offset 0 and is in order as mentioned by Julian.=20 =20 3.5.1.5 SCSI Data-out and SCSI Data-in=20 An outgoing sequence is either unsolicited (only the first sequence can be = unsolicited) or consists of all the Data-Out PDUs sent in response to an=20 R2T.=20 So in my opinion the below text rightly says "DataSequenceInOrder applies=20 only to R2T and SCSI Data in buffer offsets". Hence I think there is no=20 need for a change.=20 =20 ---------------------------------------------------------------------------= -------------------------=20 12.9 DataSequenceInOrder=20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 ---------------------------------------------------------------------------= ---------------------------=20 =20 Pls let me know your comments.=20 =20 Thanks,=20 Surekha=20 =20 From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of=20 Julian Satran Sent: Friday, September 16, 2005 11:52 AM To: Eddy Quicksall Cc: ips@ietf.org; Mallikarjun C. Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited The unsolicited data is always in order (it always start at offset zero).=20 What has to apply? Why should Mallikarjun add the text? What is the=20 question (please reformulate I have trouble understanding your point).=20 Julo=20 "Eddy Quicksall" =20 16-09-05 02:04=20 To Julian Satran/Haifa/IBM@IBMIL=20 cc , "Mallikarjun C." =20 Subject Re: [Ips] DataSequenceInOrder for non-immediate unsolicited I understand that. My question is "does this also apply to non-immediate=20 unsolicited"? I think the answer is yes but I need to get a clarification=20 on that.=20 =20 Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org=20 Sent: Thursday, September 15, 2005 2:38 PM=20 Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited=20 Eddy,=20 The unsolicited data start at offset zero. DataSequenceInOrder governs=20 only the sequence ordering.=20 Ordering within sequence is governed by DataPDUinOrder.=20 Julo=20 "Eddy Quicksall" =20 Sent by: ips-bounces@ietf.org=20 15-09-05 16:26=20 To =20 cc Subject [Ips] DataSequenceInOrder for non-immediate unsolicited 12.9 DataSequenceInOrder=20 If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred using continuously non-decreasing sequence offsets (R2T buffer offset for writes, or the smallest SCSI Data-In buffer offset within a read data sequence).=20 Up to the paren, this seems to apply to even non-immediate unsolicited but = there is a slight implication here, by distinctly referencing the R2T,=20 that this may not apply to non-immediate unsolicited PDUs. What is the=20 correct interpretation?=20 Eddy=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0062842AC225707E_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
There is another paragraph that spec= ifies that R2Ts must be served in the order they where received and the "vir= tual one" is the first.

Julo


"Eddy Quicksall&= quot; <eddy=5Fquicksall=5FiVivity=5FiSCSI@comcast.net>

16-09-05 20:04

To
<ips@ietf.org>, Julian Satran/= Haifa/IBM@IBMIL
cc
"Surekha.PC" <surekhap@= cisco.com>, <cbm@rose.hp.com>
Subject
Re: [Ips] DataSequenceInOrder for no= n-immediate unsolicited





From RFC 3720 3.2.4.2: “on each c= onnection … command N+1 MAY be sent before the unsolicited Data-Out PDUs for co= mmand N, but the unsolicited Data-out PDUs for command N MUST precede the unsolic= ited Data-Out PDUs of command N+1.”
 
Is this what you are referring to? If so it doesn't say what you have stated below.
 
Eddy

----- Original Message -----
From: Julian Satran
To: ips@ietf.org
Cc: Surekha.PC ; cb= m@rose.hp.com ; Eddy Quicksall
Sent: Friday, September 16, 2005 12:48 PM
Subject: Fw: [Ips] DataSequenceInOrder for non-im= mediate unsolicited


That is not correct. The unsolicited data is a sequence and it has to be ended before anything else happens. Unsolicited data is equivalent to a "virtual R2T" with offset 0
and R2Ts have to be honored in order.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 16-09-05 19:37 -----
"Eddy Quicksall&= quot; <eddy=5Fquicksall= =5FiVivity=5FiSCSI@comcast.net>

16-09-05 17:44 =


To
"Surekha.PC" &= lt;surekhap@cisco.com>, Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, "'Mallikarjun C.'" <cbm@rose.hp.com= >
Subject
Re: [Ips] DataSequenceInOrder for no= n-immediate unsolicited







The non-immediate unsolicited could be received out of order by the followi= ng events:
 
I-T Command
T-I R2T
 
If the initiator receives the R2T before it has begun to send the non-immed= iate unsolicited then, if DataSequenceInOrder is no, it could send the solicited data before sending the non-immediate unsolicited.
 
Eddy
----- Original Message -----
From: Surekha.PC
To: 'Julian Satran' ; 'Eddy Quicksall'
Cc: ips@ietf.org ; 'M= allikarjun C.'
Sent: Friday, September 16, 2005 3:10 AM
Subject: RE: [Ips] DataSequenceInOrder for non-immediate unsolicited

Hi Eddy,
 
I think DataSequenceInOrder "does not apply to non-immediate unsolicit= ed Data PDUs" since only the first outgoing sequence can be sent unsolici= ted, it always starts at offset 0 and is in order as mentioned by Julian.=
 
3.5.1.5 SCSI Data-out and SCSI Data-in
An outgoing sequence is either unsolicited (only the first sequence can be unsolicited) or consists of all the Data-Out PDUs sent in respon= se to an R2T.
So in my opinion the below text rightly says "DataSequenceInOrder applies only to R2T and SCSI Data in buffer offsets". Hence I think there is no need for a change.
 
---------------------------------------------------------------------------= -------------------------
12.9 DataSequenceInOrder

If DataSequenceInOrder is set to Yes, Data Sequences MUST be
transferred using continuously non-decreasing sequence offsets (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer offset
within a read data sequence). <= br> ---------------------------------------------------------------------------= ---------------------------
 
Pls let me know your comments.
 
Thanks,
Surekha
 

From: ips-bounces@ietf.org [mailt= o:ips-bounces@ietf.org] On Behalf Of Julian Satran
Sent: Friday, September 16, 2005 11:52 AM
To: Eddy Quicksall
Cc: ips@ietf.org; Mallikarjun C.
Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited


The unsolicited data is always in order (it always start at offset zero). What has to apply? Why should Mallikarjun add the text? What is the question (please reformulate I have trouble understanding your point).

Julo
"Eddy Quicksall&= quot; <eddy=5Fquicksall=5FiVivity=5FiSCSI@comcast.net>

16-09-05 02:04 =


To
Julian Satran/Haifa/IBM@= IBMIL
cc
<ips@ietf.org>, "Mallikar= jun C." <cbm@rose.hp.com>
Subject
Re: [Ips] DataSequenceInOrder for no= n-immediate unsolicited






I understand that. My question is "does this also apply to non-immedia= te unsolicited"? I think the answer is yes but I need to get a clarificat= ion on that.

Perhaps Mallikarjun could change it to (unsolicited and R2T ... ).

Eddy
----- Original Message -----
From: Julian Satran
To: Eddy Quicksall
Cc: ips@ietf.org
Sent: Thursday, September 15, 2005 2:38 PM
Subject: Re: [Ips] DataSequenceInOrder for non-immediate unsolicited

Eddy,

The unsolicited data start at offset zero. DataSequenceInOrder governs only the sequence ordering.
Ordering within sequence is governed by DataPDUinOrder.

Julo
"Eddy Quicksall&= quot; <eddy=5Fquicksall= =5FiVivity=5FiSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

15-09-05 16:26 =


To
<ips@iet= f.org>
cc
Subject
[Ips] DataSequenceInOrder for non-im= mediate unsolicited




12.9 DataSequenceInOrder

If DataSequenceInOrder is set to Yes, Data Sequences MUST be
transferred using continuously non-decreasing sequence offsets (R2T
buffer offset for writes, or the smallest SCSI Data-In buffer offset
within a read data sequence). <= br>
Up to the paren, this seems to apply to even non-immediate unsolicited but there is a slight implication here, by distinctly referencing the R2T, that this may not apply to non-immediate unsolicited PDUs. What is the correct interpretation?

Eddy=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--=_alternative 0062842AC225707E_=-- --===============1339002533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1339002533==-- From ips-bounces@ietf.org Fri Sep 16 14:57:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLOW-0007QI-2a; Fri, 16 Sep 2005 14:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLOV-0007QD-4S for ips@megatron.ietf.org; Fri, 16 Sep 2005 14:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04064 for ; Fri, 16 Sep 2005 14:57:04 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGLTX-0006SV-UE for ips@ietf.org; Fri, 16 Sep 2005 15:02:21 -0400 Received: from ivvtdkv0981 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc14) with SMTP id <2005091618565101400on00fe>; Fri, 16 Sep 2005 18:56:51 +0000 Message-ID: <00c401c5baf0$66406220$0a031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Fri, 16 Sep 2005 14:56:51 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.6 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ips] R2T issued prior to receiving unsolicited X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1629731989==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1629731989== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01C5BACE.DE9B0DA0" This is a multi-part message in MIME format. ------=_NextPart_000_00C1_01C5BACE.DE9B0DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If DataSequenceInOrder, us it legal for the target to issue an R2T = before receiving all of the unsolicited data? According to 12.9 I think it is legal to issue the R2T but not legal for = the initiator to send the data. Eddy ------=_NextPart_000_00C1_01C5BACE.DE9B0DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If DataSequenceInOrder, us it legal for the = target to=20 issue an R2T before receiving all of the unsolicited data?
 
According to 12.9 I think it is legal to issue the = R2T but not=20 legal for the initiator to send the data.
 
Eddy
------=_NextPart_000_00C1_01C5BACE.DE9B0DA0-- --===============1629731989== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1629731989==-- From ips-bounces@ietf.org Fri Sep 16 16:04:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGMRE-0006wp-NX; Fri, 16 Sep 2005 16:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGMRD-0006wM-1H for ips@megatron.ietf.org; Fri, 16 Sep 2005 16:03:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10410 for ; Fri, 16 Sep 2005 16:03:56 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGMWG-0000TH-9V for ips@ietf.org; Fri, 16 Sep 2005 16:09:13 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8GK3kTZ194448 for ; Fri, 16 Sep 2005 20:03:46 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8GK3kdg176416 for ; Fri, 16 Sep 2005 22:03:46 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8GK3kep029851 for ; Fri, 16 Sep 2005 22:03:46 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8GK3kdM029848; Fri, 16 Sep 2005 22:03:46 +0200 In-Reply-To: <00c401c5baf0$66406220$0a031eac@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] R2T issued prior to receiving unsolicited MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Fri, 16 Sep 2005 23:03:43 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 16/09/2005 23:03:46, Serialize complete at 16/09/2005 23:03:46 X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2140091979==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============2140091979== Content-Type: multipart/alternative; boundary="=_alternative 006ABE6DC225707E_=" This is a multipart message in MIME format. --=_alternative 006ABE6DC225707E_= Content-Type: text/plain; charset="US-ASCII" It is definitely legal to issue an R2T before the unsolicited data is received by the target. In fact it is even recommended (and this is why the length of unsolicited data is known in advance) to achieve a "pipelining effect" at the initiator if the RTT is significant. Julo "Eddy Quicksall" Sent by: ips-bounces@ietf.org 16-09-05 21:56 To cc Subject [Ips] R2T issued prior to receiving unsolicited If DataSequenceInOrder, us it legal for the target to issue an R2T before receiving all of the unsolicited data? According to 12.9 I think it is legal to issue the R2T but not legal for the initiator to send the data. Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 006ABE6DC225707E_= Content-Type: text/html; charset="US-ASCII"
It is definitely legal to issue an R2T before the unsolicited data is received by the target. In fact it is even recommended (and this is why the length of unsolicited data is known in advance) to achieve a "pipelining effect" at the initiator if the RTT is significant.

Julo




"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

16-09-05 21:56

To
<ips@ietf.org>
cc
Subject
[Ips] R2T issued prior to receiving unsolicited





If DataSequenceInOrder, us it legal for the target to issue an R2T before receiving all of the unsolicited data?
 
According to 12.9 I think it is legal to issue the R2T but not legal for the initiator to send the data.
 
Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 006ABE6DC225707E_=-- --===============2140091979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2140091979==-- From ips-bounces@ietf.org Mon Sep 19 11:39:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNkE-0007a9-ST; Mon, 19 Sep 2005 11:39:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNkB-0007Tr-8B for ips@megatron.ietf.org; Mon, 19 Sep 2005 11:39:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03651 for ; Mon, 19 Sep 2005 11:39:44 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHNpp-0003yh-3w for ips@ietf.org; Mon, 19 Sep 2005 11:45:37 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j8JFddpD027164; Mon, 19 Sep 2005 11:39:40 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Sep 2005 11:39:39 -0400 Message-ID: To: bwijnen@lucent.com, mbakke@cisco.com, ips@ietf.org Subject: RE: [Ips] RE: Submitted iscsi-mib-10 draft Date: Mon, 19 Sep 2005 11:39:34 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.19.14 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, LINES_OF_YELLING_3 0.671, IP_HTTP_ADDR 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __IMS_MUA 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.8 (/) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 Cc: kzm@cisco.com, mankin@psg.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bert, I believe that Mark now owes you new revisions of both drafts (iSCSI MIB and iSCSI Auth MIB). Mark should consider this a public nudge to produce them ... ;-) Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Wijnen, Bert (Bert) > Sent: Friday, September 09, 2005 5:01 PM > To: Mark Bakke; IPS > Cc: Keith McCloghrie; Allison Mankin (E-mail) > Subject: [Ips] RE: Submitted iscsi-mib-10 draft > > Sorry that it took me so long. > > > > Summary: > > I think it would be good to have a new revision that addresses > most (if not all) of my comments below. > > I note that the draft-ietf-ips-auth-mib-06.txt is a normative > reference and that one is in status "Revised ID needed" > so I am not sure I am supposed to do MIB DOctor review > now or wait for a new revision? > > > Bert > > ----- details of the review > > - I wonder if this part (from sect 6.16) > To avoid sending an excessive number of notifications due > to multiple > errors counted, an SNMP agent implementing the iSCSI MIB module > SHOULD NOT send more than three iSCSI notifications in any > 10-second > period. > Should not be provided somehwer in one or more DESCRIPTION clauses > inside the MIB itself. Maybe in the DESCRIPTION clauses of the > Notifications them selves. This to ensure that people who implement > the notifications WILL see this warning. > > - smicng tells me: > W: f(iscsi.mi2), (2620,9) Duplicate item "iscsiPortalStorageType" > in object- group "iscsiPortalAttributesGroup" OBJECTS list > The object is just listed twice. Simple to fix > > - smilint tells me: > ./ISCSI-MIB:92: [5] {integer-misuse} warning: use Integer32 > instead of INTEGER in SMIv2 > this is for IscsiTransportProtocols TC > ./ISCSI-MIB:1064: [5] {integer-misuse} warning: use Integer32 > instead of INTEGER in SMIv2 > this is for iscsiNodeErrorRecoveryLevel > ./ISCSI-MIB:2128: [5] {integer-misuse} warning: use Integer32 > instead of INTEGER in SMIv2 > this is for iscsiSsnErrorRecoveryLevel > > Probably better to use Integer32 > > - I wonder if IscsiTransportProtocols not better be > IscsiTransportProtocol > that is singular. Each time it is used for SYNTAX, I think it can > only represent ONE SINGLE protocol from the list of valid protocols > under iana registration. > > - When I see this: > IscsiName ::= TEXTUAL-CONVENTION > DISPLAY-HINT "223a" > STATUS current > DESCRIPTION > "This data type is used to define an iSCSI Name." > REFERENCE > "iSCSI Protocol Specification, Section 3.2.6, iSCSI Names." > SYNTAX OCTET STRING (SIZE(16..223)) > > Then that REFERENCE looks nice, but I have no idea where to look? > Is it RFC3720? If so why not do > REFERENCE > "RFC3720, iSCSI Protocol Specification, Section 3.2.6, > iSCSI Names." > If it is that section, then I do see it has a max size of 223 > specified in sect 3.2.6.1. > I do not see the min size of 16 ?? I suspect it is actually larger > than 16 (if I understand all subsections of 3.2.6 correct. It is > not a showstopper, I just tried to understand. > > More important is that (if I understand it all): > 3.2.6.2. iSCSI Name Encoding > > An iSCSI name MUST be a UTF-8 encoding of a string of Unicode > characters with the following properties: > > So should the TC above not say something about it being UTF8? > Maybe it should be a Utf8String as defined in SysApplMib (RFC2287) > > In any event, it would be important to indicate if the names > in an OBJECT of this SYNTAX have gone through normalization > (stringprep) or not. Or so I think. > > The DISPLAY-HINT "223a" seems to indicate that the OCTET STRING > is a ASCII string, but I doubt it is based on my reading of rfc3720. > If the string is UTF-8 (as I understand it to be) then the > DISPLAY-HINT "223t" should be used as per bullet 3, page 22 of > RFC2579. > > Further I see that when you actually use this TC to specify the > SYNTAX of an object that one time you have DESCRIPTION > iscsiInstLastSsnRmtNodeName > DESCRIPTION > "An octet string describing the name of the remote node > > and anotehr time a DESCRIPTION > iscsiNodeName > DESCRIPTION > "A character string that is a globally unique identifier for > this iSCSI node. The node name is independent of the location > > and another time a DESCRIPTION > iscsiTgtLastIntrFailureName > DESCRIPTION > "An octet string giving the name of the initiator > that failed the last login attempt." > > which just makes it all more confusing. I.e. is it an octet or a > character string. Is it UTF-8 or ASCII? Or what? > > The idea of a TC is to have one single DESCRIPTION of th esemantics > of the object type (or so I think). > > - Is there any discontinuity timer for: iscsiInstSsnFailures? > I think it is this one: iscsiInstDiscontinuityTime > But it needs to be specified in the DESCRIPTION clause of each > Counter32/Counter64 as per RFC2578 sect 7.1.6 > > Pls check for other Counter32/Counter5=64 objects as well. > > I would not be so explicit in the DESCRIPTION clause of > iscsiInstDiscontinuityTime itself. It makes it harder to use > that same timer for future Counterxx objects. > > - I see > iscsiPortalAddr OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The portal's Internet Network Address." > > Formally the DESCRIPTION clause MUST indicate which InetAddressType > object is used to define the format of this object. > > Also... is DNS possible? If so, one MUST specify when the dns name > is to be resolved. > > Pls check this for all occurences of InetAddress > > - I see > iscsiNodeInitialR2T OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the InitialR2T preference for this > node: > True = YES, > False = will try to negotiate NO, will accept YES " > > nit: I would use all lowercase for 'true' and 'false' since that > are the labels for TruthValue > > Similar remark for other cases where a TruthValue is used for > SYNTAX > > - For the read-write objects in iscsiNodeAttributesTable I do not see > any text that explains the required/expected persistence behaviour? > > Pls check that such behaviour is documented for all writable > (read-create and read-write) objects. > > - When I see > iscsiNodeErrorRecoveryLevel OBJECT-TYPE > SYNTAX INTEGER (0..255) > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The ErrorRecoveryLevel preference of this node. > Currently, only 0-2 are valid. > This object is designed to accommodate future error recover > levels. > > Then I wonder if you want to specify that 0-2 are only valid now > in the MODULE-COMPLIANCE, or in other words, ensure that a > implementation can claim compliance if they only support 0-2 > now. > > - I see: > iscsiSsnInitiatorName OBJECT-TYPE > SYNTAX IscsiName > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "If iscsiSsnDirection is Inbound, this object is an > octet string that will contain the name of the remote > initiator. If this session is a discovery session that > does not specify a particular initiator, this object > will contain a zero-length string. > If iscsiSsnDirection is Outbound, this object will > contain a zero-length string." > > But the SYNTAX clause of the IscsiName TEXTUAL CONVENTION says: > > SYNTAX OCTET STRING (SIZE(16..223)) > > SO a zero length string seems to be in conflict with that. > > - iscsiSsnInitiatorAlias OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "An octet string that gives the alias communicated by the > initiator end of the session during the login phase. > > Mmm... "An octet string" may confuse people. SnmpAdminString is > a UTF-8 string. > > Same for: iscsiSsnTargetAlias > > - When I see: > iscsiCxnLocalAddrType InetAddressType, > iscsiCxnLocalAddr InetAddress, > iscsiCxnProtocol IscsiTransportProtocols, > iscsiCxnLocalPort InetPortNumber, > iscsiCxnRemoteAddrType InetAddressType, > iscsiCxnRemoteAddr InetAddress, > Then I always wonder oif the iscsiCxnLocalAddr and > iscsiCxnRemoteAddr > MUST be of the same InetAddressType. If so, then you only need > to have one such InetAddressType object and probably that is what > you want in that case, because it makes it easier to ensure that > both address types are the same. > > See also my earlier remakrs about InetAddress (i.e. need to state > which InetAddresType object specifies the format and need to say > when DNS names are resolved (if they are valid types). > > - iscsiCxnLocalPort OBJECT-TYPE > SYNTAX InetPortNumber > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The local transport protocol port used by this connection." > > According to RFC3291 (now obsoleted by RFC4001 by the way) you MUST > describe what the meaning is of a portnuumber value zero. > > same for iscsiCxnRemotePort > > - I do not understand why you do: > > iscsiNotifications OBJECT IDENTIFIER ::= { iscsiMibModule 0 } > > ... > > iscsiNotificationsPrefix OBJECT IDENTIFIER ::= { > iscsiNotifications 0 } > > cause that gives you an OID for notifications that ends in 0.0.x > and that I think we do not want. So I would just root the > notifications > under iscsiNotifications and forget about the xxxPrefix. > > - I see comment lines like: > > ------------------------------------------------------------------ > > They are OK but I find them dangerous, cause they MUST be a multiple > of two dashes othersise it causes trouble. If you need/want a > separator line I prefer to see: > > --**************************************************************** > > - I see: > iscsiComplianceV1 MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Initial version of compliance statement based on > initial version of this MIB module. > > If an implementation can be both a target and an > initiator, all groups are mandatory." > > In principle there is nothing wrong. I personally always wonder if > it does not make more sense to make that 2 Compliances, one for > targets and one for initiators. It makes it much easier to > specify compliance in "mandatory groups" as opposed to large > sets of optional or conditionally optional groups. > > - You have the SCSIMIB as Informative reference. > But you have RowPointer(s) pointing to entries in that MIB > module, so to me that sort of indicates it is a normative > reference, no? > > Just for completeness: > > $ idnits draft-ietf-ips-iscsi-mib-10.txt > idnits 1.77 (21 Aug 2005) > > draft-ietf-ips-iscsi-mib-10.txt: > > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > Checking conformance with RFC 3978/3979 boilerplate... > * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure > Acknowledgement -- however, there's a paragraph with a > matching beginning. > Boilerplate error? > (The document uses RFC 3667 boilerplate or RFC 3978-like > boilerplate > instead of verbatim RFC 3978 boilerplate. After 6 May > 2005, submission of > drafts without verbatim RFC 3978 boilerplate is not accepted.) > > Bert > > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Sunday, February 20, 2005 20:35 > > To: IPS > > Cc: Bert Wijnen; Keith McCloghrie > > Subject: Submitted iscsi-mib-10 draft > > > > > > > > I've just submitted iscsi-mib-10 as an internet draft, to > address MIB > > Doctor review > > comments as well as clean up a few things. Until it pops > out of the > > draft queue, it's > > available in: > > > > ftp://ftpeng.cisco.com/mbakke/ips/iscsi-mib/ > > > > A new UML model showing the one update to the MIB structure > > (the addition of a node index to the initiator and target portal > > structure to address comments from long ago) is also available in > > the same location, along with the plain .mi2 for compiling, and > > diffs of the MIB module itself from -09. > > > > Thanks to Jim Muchow, Keith McCloghrie, and Marjorie Krueger > > for help in working through this last set of edits, and to Bert > > Wijnen (MIB Doctor) for his constructive (and educational, for > > me anyway) comments. > > > > Major changes to this module are: > > > > - The addition of node index to initiator and target portals > > - The addition of StorageType objects > > - Better text for all RowStatus objects > > - Better text for all Index objects > > - Addition of DiscontinuityTime objects for instances and nodes > > - Improved SNMP terminology throughout > > - Some renumbering of higher-level objects was necessary to > > make use of more standard numbering schemes and to add > > the index values on the portals > > - A large number of REFERENCE statements were added > > - Changed objects from INTEGER to Unsigned32 except for enums > > - Renamed iscsiSsnDigestErrors to iscsiSsnCxnDigestErrors > > > > As there were quite a few changes to this document, it is > very likely > > that I've either missed something in the editing, or > perhaps have not > > completely addressed the review comments. Please let me know > > if there's anything missing. > > > > Thanks, > > > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 952-967-8374 > > > > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 19 12:00:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHO4f-0005OL-MK; Mon, 19 Sep 2005 12:00:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHO4e-0005OC-99 for ips@megatron.ietf.org; Mon, 19 Sep 2005 12:00:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04724 for ; Mon, 19 Sep 2005 12:00:53 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHOAG-0004WZ-Lb for ips@ietf.org; Mon, 19 Sep 2005 12:06:47 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j8JG0m3v010929; Mon, 19 Sep 2005 12:00:50 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Sep 2005 12:00:47 -0400 Message-ID: To: cbm@rose.hp.com Subject: RE: [Ips] Discovery text Date: Mon, 19 Sep 2005 12:00:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.19.16 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > It would seem to me that since there may be a requirement to > change existing code to comply with this you should increase > the version number. That's not going to happen, but something does need to be done about negotiation to avoid breaking things ... 5.1 Error Recovery for Discovery Sessions The negotiation of the key ErrorRecoveryLevel is irrelevant for Discovery sessions - i.e. for sessions that negotiated "SessionType=Discovery". The operational ErrorRecoveryLevel for Discovery sessions MUST be 0. This naturally follows from the functionality constraints [RFC3720] imposes on Discovery sessions. As written, this allows an ErrorRecoveryLevel=Irrelevant response on a discovery session, which may cause problems for an implementation that is not expecting such a response. The text needs to instead - Note/warn that older implementations may attempt to use non-zero ERL on a discovery session, and it is therefore not an error to receive such an attempt, - But if ERL is negotiated on a discovery session, it MUST be offered and responded to as zero. Older implementations would escape the second bullet's "MUST" by not claiming compliance to the implementers guide RFC. Fortunately, ERL negotiation has a "minimum" result function, so one side can force it to zero without the other's cooperation. For the ISID rule clarifications, we need to make sure that an implementation respecting the new rules does something reasonable at ERL 0 when talking to a system that has not complied with the clarifications. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 19 17:53:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHTaD-0006XZ-A5; Mon, 19 Sep 2005 17:53:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHTaC-0006We-69 for ips@megatron.ietf.org; Mon, 19 Sep 2005 17:53:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01045 for ; Mon, 19 Sep 2005 17:53:49 -0400 (EDT) Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHTfr-0007GX-I5 for ips@ietf.org; Mon, 19 Sep 2005 17:59:45 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel7.hp.com (Postfix) with ESMTP id 2593C2807; Mon, 19 Sep 2005 17:52:22 -0400 (EDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.62]) by rosemail.rose.hp.com (Postfix) with ESMTP id CB7F87FFB; Mon, 19 Sep 2005 14:42:01 -0700 (PDT) Message-ID: <432F3312.100@rose.hp.com> Date: Mon, 19 Sep 2005 14:52:18 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] Discovery text References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > As written, this allows an ErrorRecoveryLevel=Irrelevant response > on a discovery session That wasn't what I intended (didn't use the capitalized Irrelevant), but I can now see how that can be read into what I wrote. >The text needs to instead OK, I will incorporate the suggestions. > For the ISID rule clarifications, we need to make sure that an > implementation respecting the new rules does something reasonable > at ERL 0 I am not certain that the new UNNAMED ISID RULE interacts with error recovery or its negotiation. Please let me know if you see it otherwise. Thanks! Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Black_David@emc.com wrote: >>It would seem to me that since there may be a requirement to >>change existing code to comply with this you should increase >>the version number. > > > That's not going to happen, but something does need to be done > about negotiation to avoid breaking things ... > > 5.1 Error Recovery for Discovery Sessions > > The negotiation of the key ErrorRecoveryLevel is irrelevant for > Discovery sessions - i.e. for sessions that negotiated > "SessionType=Discovery". The operational ErrorRecoveryLevel for > Discovery sessions MUST be 0. This naturally follows from the > functionality constraints [RFC3720] imposes on Discovery sessions. > > As written, this allows an ErrorRecoveryLevel=Irrelevant response > on a discovery session, which may cause problems for an implementation > that is not expecting such a response. The text needs to instead > - Note/warn that older implementations may attempt to use non-zero > ERL on a discovery session, and it is therefore not an error > to receive such an attempt, > - But if ERL is negotiated on a discovery session, it MUST be > offered and responded to as zero. > Older implementations would escape the second bullet's "MUST" by > not claiming compliance to the implementers guide RFC. Fortunately, > ERL negotiation has a "minimum" result function, so one side can > force it to zero without the other's cooperation. > > For the ISID rule clarifications, we need to make sure that an > implementation respecting the new rules does something reasonable > at ERL 0 when talking to a system that has not complied with > the clarifications. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Sep 19 19:05:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHUhW-00023J-Bw; Mon, 19 Sep 2005 19:05:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHUhU-00022b-3t for ips@megatron.ietf.org; Mon, 19 Sep 2005 19:05:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06263 for ; Mon, 19 Sep 2005 19:05:24 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHUnA-0000k0-AW for ips@ietf.org; Mon, 19 Sep 2005 19:11:22 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 6BAFF870AC; Mon, 19 Sep 2005 19:05:10 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <82bfc67a48aafff1c748f9d89688245c@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery text Date: Mon, 19 Sep 2005 16:04:54 -0700 To: Black_David@emc.com X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ips@ietf.org, cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0441517244==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0441517244== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-687523217" Content-Transfer-Encoding: 7bit --Apple-Mail-3-687523217 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Sep 19, 2005, at 9:00 AM, Black_David@emc.com wrote: > That's not going to happen, but something does need to be done > about negotiation to avoid breaking things ... > > For the ISID rule clarifications, we need to make sure that an > implementation respecting the new rules does something reasonable > at ERL 0 when talking to a system that has not complied with > the clarifications. I think the problem is that things don't work well without the clarifications. This particular part of things isn't (AFAICT) one where we had one working behavior which we want to replace with another, but it is a place where we had a mess we want to clean up. :-) Take care, Bill --Apple-Mail-3-687523217 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDL0QjDJT2Egh26K0RAj8cAJoDM+hH6/Sq78rBgif+mQTpGAkrsACdF1nW UCtBHJzRjmiR34rM+xByow8= =5pFc -----END PGP SIGNATURE----- --Apple-Mail-3-687523217-- --===============0441517244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0441517244==-- From ips-bounces@ietf.org Tue Sep 20 09:41:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHiNO-0006lF-Qy; Tue, 20 Sep 2005 09:41:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHiNN-0006l6-05 for ips@megatron.ietf.org; Tue, 20 Sep 2005 09:41:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00470 for ; Tue, 20 Sep 2005 09:41:35 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHiTB-0004yz-Ub for ips@ietf.org; Tue, 20 Sep 2005 09:47:39 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j8KDfUCv025362 for ; Tue, 20 Sep 2005 09:41:31 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Sep 2005 09:41:29 -0400 Message-ID: To: ips@ietf.org Date: Tue, 20 Sep 2005 09:41:17 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.20.10 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.8 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ips] FCIP MIB - Author APB X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I do not have current email addresses for either author of the FCIP MIB (draft-ietf-ips-fcip-mib-07.txt), Anil Rijhsinghani or Ravi Natarajan. If anyone knows where they are, they need to contact me ASAP - this MIB needs to be revised based on expert review comments. Also, just in case these authors cannot be located, anyone interested in taking on editorship of this MIB should contact me promptly. If there is no interest in further work on this MIB, it will be abandoned, and I'd prefer not to have to do that. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 20 10:20:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHiyf-0007GN-PF; Tue, 20 Sep 2005 10:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHiye-0007FH-27 for ips@megatron.ietf.org; Tue, 20 Sep 2005 10:20:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03391 for ; Tue, 20 Sep 2005 10:20:05 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHj4S-0005wP-4u for ips@ietf.org; Tue, 20 Sep 2005 10:26:10 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j8KEK054020159 for ; Tue, 20 Sep 2005 10:20:01 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Sep 2005 10:19:59 -0400 Message-ID: To: ips@ietf.org Date: Tue, 20 Sep 2005 10:19:52 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.20.12 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Black_David@emc.com Subject: [Ips] IPS WG Last Call: iSER revisions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is to announce an IP Storage (ips) Working Group Last Call on the revisions to the iSER draft: iSCSI Extensions for RDMA Specification draft-ietf-ips-iser-04.txt that are specified in: Generalization of iSER for InfiniBand and other Network Protocols draft-hufferd-iser-ib-01.txt The result of the WG Last Call will be a revised version of the iSER draft, but the WG Last Call is solely on the revisions in draft-hufferd-iser-ib-01.txt . Settled technical issues in the iSER draft will not be reopened. Versions of what the iSER draft would look like with these changes applied are available at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iser-05_candidate.txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iser-05_candidate.pdf The TXT shows the proposed result, and the PDF shows all of the proposed additions and deletions - many thanks to Mike Ko for preparing these. This WG Last Call will end at 12:00 midnight (end of day) on October 7, 2005. As this WG Last Call is concerned entirely with editorial changes, all comments and requests for any change to the text should be posted to the list. Thanks, --David (IPS WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 20 15:50:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHo87-0001Y7-I8; Tue, 20 Sep 2005 15:50:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHo7v-0001TJ-7g; Tue, 20 Sep 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26888; Tue, 20 Sep 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHoDn-00085C-DY; Tue, 20 Sep 2005 15:56:08 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EHo7t-0001zx-Kn; Tue, 20 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 20 Sep 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-impl-guide-01.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --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 Implementer's Guide Author(s) : M. Chadalapaka Filename : draft-ietf-ips-iscsi-impl-guide-01.txt,.pdf Pages : 24 Date : 2005-9-20 iSCSI is a SCSI transport protocol and maps the SCSI family of application protocols onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-impl-guide-01.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-impl-guide-01.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: <2005-9-20104440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-impl-guide-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-20104440.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Tue Sep 20 16:24:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHofI-0000Vh-33; Tue, 20 Sep 2005 16:24:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHofG-0000VZ-4L for ips@megatron.ietf.org; Tue, 20 Sep 2005 16:24:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03724 for ; Tue, 20 Sep 2005 16:24:27 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHol9-0002Oq-DQ for ips@ietf.org; Tue, 20 Sep 2005 16:30:35 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j8KKOJfQ009749 for ; Tue, 20 Sep 2005 16:24:20 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Sep 2005 16:24:16 -0400 Message-ID: To: ips@ietf.org Date: Tue, 20 Sep 2005 16:24:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.20.24 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Ips] I-D announcement bounces X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Everyone, Please pardon this interruption ... IETF Internet Draft announcements include a URL as an email attachment. The announcement of the implementer's guide draft (forwarded below) generated a number of bounces from email servers that refuse to delivering email with URL attachments. If you did not receive the message forwarded below, you might want to talk to your email administrator. FYI, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, September 20, 2005 3:50 PM > To: i-d-announce@ietf.org > Cc: ips@ietf.org > Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-impl-guide-01.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the IP Storage Working Group of the IETF. > > Title : iSCSI Implementer's Guide > Author(s) : M. Chadalapaka > Filename : draft-ietf-ips-iscsi-impl-guide-01.txt,.pdf > Pages : 24 > Date : 2005-9-20 > > iSCSI is a SCSI transport protocol and maps the SCSI family > of application protocols onto TCP/IP. RFC 3720 defines the > iSCSI protocol. This document compiles the clarifications to > the original protocol definition in RFC 3720 to serve as a > companion document for the iSCSI implementers. This document > updates RFC 3720 and the text in this document supersedes the > text in RFC 3720 when the two differ. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl- > guide-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ips-iscsi-impl-guide-01.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-impl-guide-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Sep 20 16:58:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpCF-00048y-RZ; Tue, 20 Sep 2005 16:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpCB-00048Q-Gi for ips@megatron.ietf.org; Tue, 20 Sep 2005 16:58:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05338 for ; Tue, 20 Sep 2005 16:58:28 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpI4-0003Bu-5b for ips@ietf.org; Tue, 20 Sep 2005 17:04:37 -0400 Received: from ivvtdkv0981 (unknown[64.238.111.98]) by comcast.net (rwcrmhc14) with SMTP id <2005092020581901400nrq7je>; Tue, 20 Sep 2005 20:58:19 +0000 Message-ID: <001201c5be26$07c43120$3201a8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Tue, 20 Sep 2005 16:58:18 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ips] Nop-in LUN X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0178189977==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0178189977== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C5BE04.80022CE0" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C5BE04.80022CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have always wondered why the LUN is required in a NOP-in with a valid = TTT. Can anyone explain that? Eddy ------=_NextPart_000_000F_01C5BE04.80022CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have always wondered why the LUN is required in a = NOP-in=20 with a valid TTT. Can anyone explain that?
 
Eddy
------=_NextPart_000_000F_01C5BE04.80022CE0-- --===============0178189977== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0178189977==-- From ips-bounces@ietf.org Wed Sep 21 06:47:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI28I-0006kw-LR; Wed, 21 Sep 2005 06:47:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI28H-0006kb-0T for ips@megatron.ietf.org; Wed, 21 Sep 2005 06:47:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11123 for ; Wed, 21 Sep 2005 06:47:18 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI2EF-0005sj-Ns for ips@ietf.org; Wed, 21 Sep 2005 06:53:34 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j8LAl8d7182504 for ; Wed, 21 Sep 2005 10:47:08 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8LAl8xI159406 for ; Wed, 21 Sep 2005 12:47:08 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j8LAl8OH005668 for ; Wed, 21 Sep 2005 12:47:08 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j8LAl8V6005665; Wed, 21 Sep 2005 12:47:08 +0200 In-Reply-To: <001201c5be26$07c43120$3201a8c0@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] Nop-in LUN MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Julian Satran Message-ID: Date: Wed, 21 Sep 2005 13:47:06 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 21/09/2005 13:47:08, Serialize complete at 21/09/2005 13:47:08 X-Spam-Score: 0.8 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0347126065==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0347126065== Content-Type: multipart/alternative; boundary="=_alternative 003809AAC2257083_=" This is a multipart message in MIME format. --=_alternative 003809AAC2257083_= Content-Type: text/plain; charset="US-ASCII" The archives will probably point you to a discussion in early 2000. The LUN is there to enable implementations that have behind the target several execution units each in charge of several LUs and handing out TTTs that are not unique over the "total" target. (unlike ITT the RFC3720 does not require a unique TTT per target). I addition the job of a gateway is simplified if outgoing PDUs contain the LUN (a gateway may have several "real Targets" behind it too). Julo "Eddy Quicksall" Sent by: ips-bounces@ietf.org 20-09-05 23:58 To cc Subject [Ips] Nop-in LUN I have always wondered why the LUN is required in a NOP-in with a valid TTT. Can anyone explain that? Eddy_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 003809AAC2257083_= Content-Type: text/html; charset="US-ASCII"
The archives will probably point you to a discussion in early 2000. The LUN is there to enable implementations that have behind the target several execution units each in charge of several LUs and handing out TTTs that are not unique over the "total" target. (unlike ITT the RFC3720 does not require a unique TTT per target). I addition the job of a gateway is simplified if outgoing PDUs contain the LUN (a gateway may have several "real Targets" behind it too).

Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-bounces@ietf.org

20-09-05 23:58

To
<ips@ietf.org>
cc
Subject
[Ips] Nop-in LUN





I have always wondered why the LUN is required in a NOP-in with a valid TTT. Can anyone explain that?
 
Eddy_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 003809AAC2257083_=-- --===============0347126065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0347126065==-- From ips-bounces@ietf.org Wed Sep 21 16:37:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBLr-00046U-PW; Wed, 21 Sep 2005 16:37:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBLq-00046M-FM; Wed, 21 Sep 2005 16:37:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27588; Wed, 21 Sep 2005 16:37:56 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIBRw-00014g-ET; Wed, 21 Sep 2005 16:44:16 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8LKbZn23352; Wed, 21 Sep 2005 13:37:35 -0700 (PDT) Message-Id: <200509212037.j8LKbZn23352@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 21 Sep 2005 13:37:35 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 4171 on Internet Storage Name Service (iSNS) X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4171 Title: Internet Storage Name Service (iSNS) Author(s): J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. Souza Status: Standards Track Date: September 2005 Mailbox: joshtseng@yahoo.com, kevin.gibbons@mcdata.com, travos@nortel.com, cdl@rincon.com, joes@exmsft.com Pages: 123 Characters: 310636 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-isns-22.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4171.txt This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) 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 capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050921133632.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4171 --OtherAccess Content-Type: Message/External-body; name="rfc4171.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050921133632.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Wed Sep 21 16:40:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBNy-0004bt-Ml; Wed, 21 Sep 2005 16:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBNv-0004bV-LQ; Wed, 21 Sep 2005 16:40:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27836; Wed, 21 Sep 2005 16:40:05 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIBTv-0001Bc-5m; Wed, 21 Sep 2005 16:46:26 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8LKd8n24044; Wed, 21 Sep 2005 13:39:08 -0700 (PDT) Message-Id: <200509212039.j8LKd8n24044@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 21 Sep 2005 13:39:08 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 4172 on iFCP - A Protocol for Internet Fibre Channel Storage Networking X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4172 Title: iFCP - A Protocol for Internet Fibre Channel Storage Networking Author(s): C. Monia, R. Mullendore, F. Travostino, W. Jeong, M. Edwards Status: Standards Track Date: September 2005 Mailbox: charles_monia@yahoo.com, Rod.Mullendore@MCDATA.com, travos@nortel.com, wayland@TroikaNetworks.com, mark_edwards@adaptec.com Pages: 111 Characters: 241908 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-ifcp-14.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4172.txt This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network. This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050921133803.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4172 --OtherAccess Content-Type: Message/External-body; name="rfc4172.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050921133803.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Wed Sep 21 16:42:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBPq-0004uo-3l; Wed, 21 Sep 2005 16:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBPl-0004uA-NF; Wed, 21 Sep 2005 16:42:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28014; Wed, 21 Sep 2005 16:41:59 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIBVo-0001Gx-O5; Wed, 21 Sep 2005 16:48:17 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j8LKf5n24806; Wed, 21 Sep 2005 13:41:05 -0700 (PDT) Message-Id: <200509212041.j8LKf5n24806@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 21 Sep 2005 13:41:05 -0700 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ips@ietf.org, rfc-editor@rfc-editor.org Subject: [Ips] RFC 4173 on Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4173 Title: Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol Author(s): P. Sarkar, D. Missimer, C. Sapuntzakis Status: Standards Track Date: September 2005 Mailbox: psarkar@almaden.ibm.com, duncan.missimer@ieee.org, csapuntz@alum.mit.edu Pages: 12 Characters: 27105 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-iscsi-boot-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4173.txt Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling 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. This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050921134005.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4173 --OtherAccess Content-Type: Message/External-body; name="rfc4173.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050921134005.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Thu Sep 22 09:06:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIQm1-0006AK-5k; Thu, 22 Sep 2005 09:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIQlm-00064m-Cp for ips@megatron.ietf.org; Thu, 22 Sep 2005 09:05:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27795 for ; Thu, 22 Sep 2005 09:05:44 -0400 (EDT) Message-Id: <200509221305.JAA27795@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIQs0-0000FV-3U for ips@ietf.org; Thu, 22 Sep 2005 09:12:13 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIQla-000L3x-Ju; Thu, 22 Sep 2005 13:05:34 +0000 To: "Wijnen, Bert (Bert)" Date: Thu, 22 Sep 2005 06:05:34 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Kevin Gibbons , Annie Wang , "Charles Monia \(email\)" , "Mike MacFaden \(E-mail\)" , Jayesh Gada , kzm@cisco.com, Black_David@emc.com, Scott Kipp , Joe White , mrm@macfaden.com, travos@nortelnetworks.com, ElizabethRodriguez@ieee.org, Josh Tseng , "Ipswg \(E-mail\)" , Larry Hofer Subject: [Ips] Re: MIB Doctor review: draft-ietf-ips-ifcp-mib-06.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bert, This MIB finished its Last Call today with no comments. As you noted, it has been a very long time since its birth, and in honor of the fact that the iFCP RFC has come out, I wonder if we can help keep this MIB moving by taking your Last Call comments into Notes to the RFC Editor Editor instead of a new spin of the draft. I read them over and I think we could make this without too much difficulty. I'd like to put the iFCP MIB on the IESG's agenda for the 29th. Allison _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 22 09:47:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRQ2-0002KY-Hx; Thu, 22 Sep 2005 09:47:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRPy-0002J1-CF for ips@megatron.ietf.org; Thu, 22 Sep 2005 09:47:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00175 for ; Thu, 22 Sep 2005 09:47:16 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIRWC-0001QH-Am for ips@ietf.org; Thu, 22 Sep 2005 09:53:45 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8MDkB96022501; Thu, 22 Sep 2005 08:46:11 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 22 Sep 2005 15:46:10 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508234045@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Allison Mankin , "Wijnen, Bert (Bert)" Date: Thu, 22 Sep 2005 15:46:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Kevin Gibbons , Annie Wang , "Charles Monia \(email\)" , "Mike MacFaden \(E-mail\)" , Jayesh Gada , kzm@cisco.com, Black_David@emc.com, Scott Kipp , Joe White , mrm@macfaden.com, travos@nortelnetworks.com, ElizabethRodriguez@ieee.org, Josh Tseng , "Ipswg \(E-mail\)" , Larry Hofer Subject: [Ips] RE: MIB Doctor review: draft-ietf-ips-ifcp-mib-06.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org If you prefer to do it with notes-to-rfc-editor, that is fine by me. Pls put them in ID tracker so I can check. Bert > -----Original Message----- > From: Allison Mankin [mailto:mankin@psg.com] > Sent: Thursday, September 22, 2005 15:06 > To: Wijnen, Bert (Bert) > Cc: Kevin Gibbons; kzm@cisco.com; Ipswg (E-mail); > mrm@macfaden.com; Mike > MacFaden (E-mail); Black_David@emc.com; ElizabethRodriguez@ieee.org; > Scott Kipp; Larry Hofer; G D Ramkumar; Charles Monia (email); Josh > Tseng; travos@nortelnetworks.com; Jayesh Gada; Annie Wang; Joe White > Subject: Re: MIB Doctor review: draft-ietf-ips-ifcp-mib-06.txt > > > Bert, > > This MIB finished its Last Call today with no comments. > > As you noted, it has been a very long time since its birth, > and in honor of the fact that the iFCP RFC has come out, > I wonder if we can help keep this MIB moving by taking > your Last Call comments into Notes to the RFC Editor > Editor instead of a new spin of the draft. I read them > over and I think we could make this without too much > difficulty. > > I'd like to put the iFCP MIB on the IESG's agenda for > the 29th. > > Allison > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Sep 22 15:45:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIX0X-0000ld-81; Thu, 22 Sep 2005 15:45:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIX0V-0000lK-5Q for ips@megatron.ietf.org; Thu, 22 Sep 2005 15:45:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22443 for ; Thu, 22 Sep 2005 15:45:21 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIX6l-0002uB-MC for ips@ietf.org; Thu, 22 Sep 2005 15:51:53 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id BE41887089 for ; Thu, 22 Sep 2005 15:45:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <66e2324ce98f0f62afd983c66e2e42e1@wasabisystems.com> To: IPS From: William Studenmund Date: Thu, 22 Sep 2005 12:45:00 -0700 X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Ips] Question about Reject and DataSN gaps X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0582052582==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0582052582== Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-934729017" --Apple-Mail-3-934729017 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit In talking with a customer recently, a question came up about what should happen when there's a DataSN discontinuity in a write sequence. The scenario is a write sequence where the DataSN jumps by two between two packets. So rather than ..., 2, 3, 4, 5, 6, 7, ..., we have ..., 2, 3, 5, 6, 7, 8, ... There is no disagreement that the target is supposed to notice this jump, and to either kill the task or institute some form of recovery R2T. In the specific case, DataSequenceInOrder is Yes (as there's only one outstanding R2T and ERL > 0), and so the whole initial R2T gets retried. The question though is if a Reject should be sent in response to the jump. The customer indicated that a test suite expects one. To be specific, this would be in response to the PDU that had a DataSN of 5 above. I however think that no such reject should be sent, for three reasons. First, the target will actually use the PDU; the problem isn't with this PDU, it's with some other PDU that disappeared. Or it would be if we weren't being subjected to a test. :-) Second, Reject seems appropriate for cases either where the target gets something it can't work with or where the initiator really seems to have messed up. The most likely case I can see for a DataSN gap is that we had a header digest failure and we used markers to recover other PDUs. Everything else we do in reaction to header digest failure does not use Reject on the PDUs that make it through. :-) Third, the recovery pseudocode in section E.2.3 describes this case ("if (current DataSN is not expected)"), and indicates that sending a recovery R2T is the correct action. As there are other parts of this section which explicitly indicate that sending a Reject is the correct corse of action, I believe that not sending a reject is a perfectly valid corse of action. What does everyone else think? Take care, Bill --Apple-Mail-3-934729017 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDMwnDDJT2Egh26K0RAuyIAJ0aZ0+EdA2+msLDkpHFfu37bI8P1wCfZtIj WAW1jke7gf1FaQEDZ5AutIM= =e/Pu -----END PGP SIGNATURE----- --Apple-Mail-3-934729017-- --===============0582052582== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0582052582==-- From ips-bounces@ietf.org Fri Sep 23 09:23:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EInWX-0002se-R6; Fri, 23 Sep 2005 09:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EInWQ-0002ri-8v for ips@megatron.ietf.org; Fri, 23 Sep 2005 09:23:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13904 for ; Fri, 23 Sep 2005 09:23:23 -0400 (EDT) Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIncp-0006VQ-Mv for ips@ietf.org; Fri, 23 Sep 2005 09:30:05 -0400 Received: from [192.168.7.172] (helo=winminx) by hammer with esmtp (Exim 4.12) id 1EInT6-0007Yk-00; Fri, 23 Sep 2005 14:20:00 +0100 From: "Ken Sandars" To: "'William Studenmund'" , "'IPS'" Subject: RE: [Ips] Question about Reject and DataSN gaps Date: Fri, 23 Sep 2005 14:22:23 +0100 Message-ID: <002801c5c041$ea6ebbe0$ac07a8c0@elipsan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <66e2324ce98f0f62afd983c66e2e42e1@wasabisystems.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Bill, Sounds like an overly proscriptive test suite. If you detected a data digest error you could authoritively provide a = Reject in addition to the processing you are doing. But that's not the scenario = you have described. BTW, I'd have thought it's valid to issue a Recovery-R2T for just the missing Data-Out PDU. Section 10.8 indicates Recovery-R2T PDUs are not constrained by DataSequenceInOrder. Cheers Ken >=20 > In talking with a customer recently, a question came up about what=20 > should happen when there's a DataSN discontinuity in a write sequence. >=20 > The scenario is a write sequence where the DataSN jumps by=20 > two between=20 > two packets. So rather than ..., 2, 3, 4, 5, 6, 7, ..., we=20 > have ..., 2,=20 > 3, 5, 6, 7, 8, ... >=20 > There is no disagreement that the target is supposed to notice this=20 > jump, and to either kill the task or institute some form of recovery=20 > R2T. In the specific case, DataSequenceInOrder is Yes (as=20 > there's only=20 > one outstanding R2T and ERL > 0), and so the whole initial R2T gets=20 > retried. >=20 > The question though is if a Reject should be sent in response to the=20 > jump. The customer indicated that a test suite expects one. To be=20 > specific, this would be in response to the PDU that had a DataSN of 5=20 > above. >=20 > I however think that no such reject should be sent, for three=20 > reasons.=20 > First, the target will actually use the PDU; the problem isn't with=20 > this PDU, it's with some other PDU that disappeared. Or it=20 > would be if=20 > we weren't being subjected to a test. :-) Second, Reject seems=20 > appropriate for cases either where the target gets something it can't=20 > work with or where the initiator really seems to have messed up. The=20 > most likely case I can see for a DataSN gap is that we had a header=20 > digest failure and we used markers to recover other PDUs. Everything=20 > else we do in reaction to header digest failure does not use=20 > Reject on=20 > the PDUs that make it through. :-) >=20 > Third, the recovery pseudocode in section E.2.3 describes this case=20 > ("if (current DataSN is not expected)"), and indicates that sending a=20 > recovery R2T is the correct action. As there are other parts of this=20 > section which explicitly indicate that sending a Reject is=20 > the correct=20 > corse of action, I believe that not sending a reject is a perfectly=20 > valid corse of action. >=20 > What does everyone else think? >=20 > Take care, >=20 > Bill >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Sep 30 20:29:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELVFo-000636-4s; Fri, 30 Sep 2005 20:29:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELVFm-00062z-5g for ips@megatron.ietf.org; Fri, 30 Sep 2005 20:29:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00788 for ; Fri, 30 Sep 2005 20:29:25 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELVNj-00041M-6T for ips@ietf.org; Fri, 30 Sep 2005 20:37:40 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j910TMtL016696 for ; Fri, 30 Sep 2005 20:29:22 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Sep 2005 20:29:21 -0400 Message-ID: To: ips@ietf.org Date: Fri, 30 Sep 2005 20:29:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.30.32 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ips] No Vancouver meeting X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The IPS WG will NOT meet in Vancouver (Nov. 6-11), as the mailing list is sufficient to handle the WG's current activity: - iSCSI Implementers Guide. Will stay open for revisions well into 2006. - iSER and DA. Likely to be in Publication Requested state by Vancouver. - iSNS MIB The iSNS MIB is undergoing some significant revisions (the authors should be explaining what they're proposing to do and why shortly) that will require at least rough consensus of the WG and possibly another WG Last Call. Thanks, --David (IPS WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips