From mailman-bounces@ietf.org Wed Dec 1 06:53:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18524 for ; Wed, 1 Dec 2004 06:53:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZT8i-0006Xf-Pw for ips-web-archive@ietf.org; Wed, 01 Dec 2004 06:59:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZS8x-0001gf-OK for ips-web-archive@ietf.org; Wed, 01 Dec 2004 05:55:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ips-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:33:35 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ips-web-archive@ietf.org: List Password // URL ---- -------- ips@ietf.org epceek https://www1.ietf.org/mailman/options/ips/ips-web-archive%40ietf.org From ips-bounces@ietf.org Wed Dec 1 12:23:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29056 for ; Wed, 1 Dec 2004 12:23:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYHW-0005Kr-7j for ips-web-archive@ietf.org; Wed, 01 Dec 2004 12:28:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXDc-00062b-En; Wed, 01 Dec 2004 11:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZUsu-0007ws-Bs for ips@megatron.ietf.org; Wed, 01 Dec 2004 08:51:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29228 for ; Wed, 1 Dec 2004 08:51:05 -0500 (EST) Received: from smtp102.rog.mail.re2.yahoo.com ([206.190.36.80]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZUyB-0000SV-JU for ips@ietf.org; Wed, 01 Dec 2004 08:56:38 -0500 Received: from unknown (HELO Doranto) (BillMurray@rogers.com@65.48.112.58 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 1 Dec 2004 13:50:25 -0000 Message-ID: <004801c4d7ac$f1c78cb0$6502a8c0@Doranto> From: "BillMurray" Cc: References: Subject: Re: [Ips] Clarification of MaxBurstLength parameter Date: Wed, 1 Dec 2004 08:51:59 -0500 Organization: Storola MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: BillMurray List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit That clears it up, thanks. > > TOTAL of a sequence not the whole command. > > > Am I correct in thinking that MaxBurstLength governs the TOTAL amount > > of solicited data sent across the 'entire sequence' of Data-in/Data-out > > PDU's or is it the maximum length of just one Data-in/Data-out PDU? > > > > 12.13. MaxBurstLength > > > > The initiator and target negotiate maximum SCSI data payload in bytes > > in a Data-In or a solicited Data-Out iSCSI sequence. A sequence > > consists of one or more consecutive Data-In or Data-Out PDUs that end > > with a Data-In or Data-Out PDU with the F bit set to one. > > > > Thanks in advance, > > 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 Dec 2 06:28:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02132 for ; Thu, 2 Dec 2004 06:28:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZpE5-0007cL-43 for ips-web-archive@ietf.org; Thu, 02 Dec 2004 06:34:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZol2-0006Mg-Kw; Thu, 02 Dec 2004 06:04:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZocj-0006Ft-31; Thu, 02 Dec 2004 05:55:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28232; Thu, 2 Dec 2004 05:55:42 -0500 (EST) From: elizabeth.rodriguez@dothill.com Received: from artecon.dothill.com ([155.254.128.254] helo=dothill.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZoiD-0006SH-Kh; Thu, 02 Dec 2004 06:01:27 -0500 Received: from exchange.artecon.com (exchange [206.6.182.75]) by dothill.com (8.12.9+Sun/8.12.5) with ESMTP id iB2AnPXc013919; Thu, 2 Dec 2004 02:49:25 -0800 (PST) Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Dec 2004 02:52:03 -0800 Message-ID: To: ips@ietf.org Date: Thu, 2 Dec 2004 00:50:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: imss@ietf.org, T11_5@t11.org, t11_3@t11.org Subject: [Ips] Changes to FC Mgmt MIB -- Please Review! 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Hi all, The FC Mgmt MIB has completed IETF last call, but as mentioned in the IETF meeting in D.C., an IETF last call comment was inadvertently missed. This change is the addition of a column to the fcmSwitchTable. Since this is a special circumstance, we will be addressing this issue at this time. In addition, there are a few other change that have been approved to go into the draft, some editorial, and some which have been discussed on this list before. Please review the proposed changes that Keith lists below and discuss on the ips list and/or get any feedback to Keith, David and I as soon as possible. Should no discussion occur by Dec 9th, we will assume consensus and go forth with these changes. Thanks, Elizabeth > Forwarded message: > > IP Storage (ips) WG - Washington DC minutes - DRAFT > > ... > > November 8, 2004 at the IETF meetings in Washington, DC. > > ... > > FC Management MIB (draft-ietf-ips-fcmgmt-mib-05.txt) > > - New field to be added to deal with a MIB instance that > > covers multiple switches. This was submitted as an > > IETF Last Call comment, but got lost. -06 version of > > MIB will be produced containing all agreed-to changes > > from -05 plus this change. Message will be sent to > > list to do a quick review of this final change. > > > Please can you check to ensure that the following is the correct set > of changes that I need to make: > > 1.Add a new columnar object in the fcmSwitchTable: > > a) add its definition : > > fcmSwitchWWN OBJECT-TYPE > SYNTAX FcNameIdOrZero > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The World Wide Name of this switch." > ::= { fcmSwitchEntry 4 } > > b) add the object in fcmSwitchEntry's SEQUENCE, and > > c) add the object to the fcmSwitchBasicGroup which now becomes: > > fcmSwitchBasicGroup OBJECT-GROUP > OBJECTS { fcmSwitchDomainId, fcmSwitchPrincipal, fcmSwitchWWN } > STATUS current > DESCRIPTION > "Basic information about Fibre Channel switches." > ::= { fcmgmtGroups 2 } > > 2. Add to fcmInstanceFabricId's DESCRIPTION, this paragraph: > > In the event that the Fibre Channel entity/entities managed by > this management instance is/are connected to multiple fabrics, > then this object records the first (known) one. > > 3. Change in the DESCRIPTION of fcmLinkEnd2AgentAddress > > "The GS-3 specification provides example values of URLs which > indicate an SNMP, HTTP or XML agent." > -> > "The GS-4 specification provides some information about > management agents." > > 4. Remove spurious double-quote character at end of section 4.8. > > 5. The FC-MI document has been published; the reference should be > changed to: > > [FC-MI] > "Fibre Channel - Methodologies for Interconnects Technical Report > (FC-MI)" INCITS TR-30-2002. > > 6. The FC-GS-3 document has been published, the multiple references to it > should be changed to delete "Rev 7.01, 28 Nov 2000" > > 7. In the last sentence of section 5.2, change: > > "the implementation is not required ..." > -> > "the agent implementation is not required ..." > > Thanks, > Keith. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Dec 5 19:13:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21272 for ; Sun, 5 Dec 2004 19:13:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb6bp-0002zF-44 for ips-web-archive@ietf.org; Sun, 05 Dec 2004 19:20:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb6Q3-00020q-HJ; Sun, 05 Dec 2004 19:07:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cb6Ih-0001BT-Ty for ips@megatron.ietf.org; Sun, 05 Dec 2004 19:00:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20546 for ; Sun, 5 Dec 2004 19:00:20 -0500 (EST) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cb6Ov-0002l0-QZ for ips@ietf.org; Sun, 05 Dec 2004 19:06:51 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.12.10/8.12.10) with ESMTP id iB5NxlBX026285 for ; Sun, 5 Dec 2004 18:59:47 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB5NxljD253692 for ; Sun, 5 Dec 2004 18:59:47 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB5Nxle5016599 for ; Sun, 5 Dec 2004 18:59:47 -0500 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id iB5Nxl0t016595 for ; Sun, 5 Dec 2004 18:59:47 -0500 In-Reply-To: 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: Sun, 5 Dec 2004 15:59:44 -0800 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M3_11102004|November 10, 2004) at 12/05/2004 18:59:46, Serialize complete at 12/05/2004 18:59:46 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Ips] iSER Open Issues 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Here are the open issues on iSER from the last IETF meeting minutes: 1. "Draft will need to contain discussion of unexpected vs. expected PDUs and buffering requirements, and when an unexpected PDU ceases to be outstanding. Add cautionary notes to avoid NOP-out and NOP-in abuse, but take this to the list, as there may be a possibility of being able to specify initiator behavior that always works." The notes that I sent out on Nov. 11 and 12 after the IETF meeting with the subject titled "Updated text for MaxOutstandingUnexpectedPDUs for iSER" provided the new text for MaxOutstandUnexpectedPDUs. A new subsection in section 8 under Flow Control will likely be created to contain part of the new text on buffer requirements for unexpected PDUs, retiring outstanding unexpected PDUs, etc. 2. "Using a key to limit # of outstanding unexpected PDUs is the right approach. "None" = "No Limit" is allowed. Minimum value (e.g., to avoid 1 or 2) is TBD." For the unexpected PDUs from the initiator to the target, 2 is the minimum per connection per RFC3720 which states that an "iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI command per connection at any time". So it seems that 2 is the minimum value for MaxOustandingUnexpectedPDUs. Should it be bigger than 2? If so, what should it be and what is the rationale? A related question is should a different minimum value be defined for unexpected PDUs from the target to the initiator. 3. "Specified default value (None vs. specific value) in absence of negotiation will be taken to list." For the class of implementations that support SRQ, can replenish receive buffers as fast as the PDU arrival rate, and/or support graceful handling in lack of buffer situations, the choice of the default being "None" is the preferred value. Alternatively for other implementations, the argument is for a specific default value which is finite (not "None"). The preferred default value for this class of implementations could be dependent on the implemenation itself. The issue is also complicated by the negotiated value for MaxConnections. So a finite default value might be acceptable only to a subclass consisting of single connection sessions. What should this default value be and what is the rationale behind the selection? Similarly, should a different default value be defined for both the initiator side and the target side? Comments? Mike Sent by: ips-bounces@ietf.org To: ips@ietf.org cc: Subject: RE: [Ips] Draft DC minutes Having seen no comments, these are the final minutes that will be sent to the secretariat for the proceedings, and the decisions made in DC are now the rough consensus of the IP Storage WG. The iSER draft authors should take this as a cue to start list discussion on their [Open Issue]'s identified below. Thanks, --David _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Dec 6 19:43:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12423 for ; Mon, 6 Dec 2004 19:43:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbTYu-0003q3-M7 for ips-web-archive@ietf.org; Mon, 06 Dec 2004 19:50:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbTPb-0002L0-K0; Mon, 06 Dec 2004 19:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbTGm-0000GE-QA for ips@megatron.ietf.org; Mon, 06 Dec 2004 19:31:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11227 for ; Mon, 6 Dec 2004 19:31:52 -0500 (EST) Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbTNE-0003Wx-8u for ips@ietf.org; Mon, 06 Dec 2004 19:38:36 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel7.hp.com (Postfix) with ESMTP id 2306BB8C8 for ; Mon, 6 Dec 2004 19:31:54 -0500 (EST) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.45.109]) by rosemail.rose.hp.com (Postfix) with ESMTP id CAB5B7FFF for ; Mon, 6 Dec 2004 16:31:53 -0800 (PST) Message-ID: <41B4F9F9.3010404@rose.hp.com> Date: Mon, 06 Dec 2004 16:31:53 -0800 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] iSER Open Issues 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: bdc523f9a54890b8a30dd6fd53d5d024 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit IMO, a default of None makes sense since these are essentially RFC 3720 semantics (and RFC 3720-compliant implementations do not negotiate/understand the new key). Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Mike Ko wrote: > Here are the open issues on iSER from the last IETF meeting minutes: > > 1. "Draft will need to contain discussion of unexpected vs. expected PDUs > and buffering requirements, and when an unexpected PDU ceases to be > outstanding. Add cautionary notes to avoid NOP-out and NOP-in abuse, but > take this to the list, as there may be a possibility of being able to > specify initiator behavior that always works." The notes that I sent out > on Nov. 11 and 12 after the IETF meeting with the subject titled "Updated > text for MaxOutstandingUnexpectedPDUs for iSER" provided the new text for > MaxOutstandUnexpectedPDUs. A new subsection in section 8 under Flow > Control will likely be created to contain part of the new text on buffer > requirements for unexpected PDUs, retiring outstanding unexpected PDUs, > etc. > > 2. "Using a key to limit # of outstanding unexpected PDUs is the right > approach. "None" = "No Limit" is allowed. Minimum value (e.g., to avoid > 1 or 2) is TBD." For the unexpected PDUs from the initiator to the > target, 2 is the minimum per connection per RFC3720 which states that an > "iSCSI target MUST be able to handle at least one immediate task > management command and one immediate non-task-management iSCSI command per > connection at any time". So it seems that 2 is the minimum value for > MaxOustandingUnexpectedPDUs. Should it be bigger than 2? If so, what > should it be and what is the rationale? A related question is should a > different minimum value be defined for unexpected PDUs from the target to > the initiator. > > 3. "Specified default value (None vs. specific value) in absence of > negotiation will be taken to list." For the class of implementations that > support SRQ, can replenish receive buffers as fast as the PDU arrival > rate, and/or support graceful handling in lack of buffer situations, the > choice of the default being "None" is the preferred value. Alternatively > for other implementations, the argument is for a specific default value > which is finite (not "None"). The preferred default value for this class > of implementations could be dependent on the implemenation itself. The > issue is also complicated by the negotiated value for MaxConnections. So > a finite default value might be acceptable only to a subclass consisting > of single connection sessions. What should this default value be and what > is the rationale behind the selection? Similarly, should a different > default value be defined for both the initiator side and the target side? > > Comments? > > Mike > Sent by: ips-bounces@ietf.org > To: ips@ietf.org > cc: > Subject: RE: [Ips] Draft DC minutes > > > > Having seen no comments, these are the final minutes that will be > sent to the secretariat for the proceedings, and the decisions > made in DC are now the rough consensus of the IP Storage WG. > > The iSER draft authors should take this as a cue to start > list discussion on their [Open Issue]'s identified below. > > Thanks, > --David > > _______________________________________________ > 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 Dec 7 13:24:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02871 for ; Tue, 7 Dec 2004 13:24:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbk7j-0002OX-7R for ips-web-archive@ietf.org; Tue, 07 Dec 2004 13:31:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbjnc-0003nE-JZ; Tue, 07 Dec 2004 13:10:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbjan-0001gj-IN for ips@megatron.ietf.org; Tue, 07 Dec 2004 12:57:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29774 for ; Tue, 7 Dec 2004 12:57:38 -0500 (EST) Received: from ppp-67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=silexch.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbjhO-0001lV-TB for ips@ietf.org; Tue, 07 Dec 2004 13:04:31 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Dec 2004 09:58:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: iSER Open Issues Thread-Index: AcTcgTax9i6aF4lNQCCVpN0kfU+giQABCmgg From: "Caitlin Bestler" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Subject: [Ips] RE: iSER Open Issues 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable > From: "Mallikarjun C." > Subject: Re: [Ips] iSER Open Issues >=20 > IMO, a default of None makes sense since these are=20 > essentially RFC 3720 semantics (and RFC 3720-compliant=20 > implementations do not negotiate/understand the new key). >=20 That is only true from the sending perspective, where "None" essentially means "don't worry about it", and that does match TCP semantics. You don't have to worry about overflowing the target because TCP bottlenecking will efficiently prevent that. But that is *not* the case at the other end. Instead of meaning, "you can read these at whatever pace you want, it will only impact Performance, not correctness" selecting "NONE" means you MUST at least accept these messages from the transport layer at full speed. I agree with the concern raised at the DC meeting that this is not an appropriate default. An implementation that does not know To set the key is probably *not* capable of meeting the requirements of "NONE", and any capable of doing so would have no problem explicitly setting the limit. That said, explicitly setting the key is not that hard for *anyone*, so What the default value is is really not that important, as long as it is defined. However, for simplicity of the specification I would recommend that it either be the minimum or "NONE". That way no third special value is=20 created. -- Caitlin Bestler Director Software Architecture Siliquent Technologies caitlinb@siliquent.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 8 11:53:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13523 for ; Wed, 8 Dec 2004 11:53:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5Af-00020O-64 for ips-web-archive@ietf.org; Wed, 08 Dec 2004 12:00:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc4xc-00006A-Jw; Wed, 08 Dec 2004 11:46:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc38N-0000Ux-2q for ips@megatron.ietf.org; Wed, 08 Dec 2004 09:49:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00895 for ; Wed, 8 Dec 2004 09:49:37 -0500 (EST) Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc3F7-0007FG-2o for ips@ietf.org; Wed, 08 Dec 2004 09:56:40 -0500 Received: from smtp1.corp.netapp.com (10.57.156.124) by mx2.netapp.com with ESMTP; 08 Dec 2004 06:49:06 -0800 X-Ironport-AV: i="3.87,130,1099296000"; d="scan'217,208"; a="68949932:sNHT20830624" Received: from svlexc02.hq.netapp.com (svlexc02.corp.netapp.com [10.57.157.136]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id iB8En4MY018533 for ; Wed, 8 Dec 2004 06:49:04 -0800 (PST) Received: from RTPEXC02.hq.netapp.com ([10.60.4.11]) by svlexc02.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Dec 2004 06:49:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 8 Dec 2004 09:49:02 -0500 Message-ID: Thread-Topic: iSCSI: Session continuation and ERL=0 Thread-Index: AcTdNRFctyoL0oaHQGel9i6qZqO+/Q== From: "Pittman, Joseph" To: X-OriginalArrivalTime: 08 Dec 2004 14:49:04.0077 (UTC) FILETIME=[0FC4AFD0:01C4DD35] X-Spam-Score: 0.8 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-Mailman-Approved-At: Wed, 08 Dec 2004 11:46:39 -0500 Subject: [Ips] iSCSI: Session continuation and ERL=0 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="===============1650669697==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d This is a multi-part message in MIME format. --===============1650669697== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DD35.0F09769B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DD35.0F09769B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question about session continuation and ErrorRecoveryLevel=3D0 sessions.=20 =20 In short: In an ERL=3D0 session, is a session allowed to persist beyond the loss of its last constituent TCP connection? =20 I think the answer is yes, and my reasoning is based partly on text in Section 5.3.6 of RFC3720. That section describes Session Continuation as =20 "the process by which a preexisting session continues to be used by connection reinstatement... or by adding a connection with a new CID." =20 No mention is made of ErrorRecoveryLevel. This leads me to think that as long as the target supports session continuation in this case, and as long as the initiator adds a new connection to the session in a timely fashion, the session can survive loss of its last TCP connection. =20 In general, my understanding is that, whenever ANY connection is terminated on an ERL=3D0 session, all commands allegiant to THAT connection are immediately terminated at the target. But the session can survive loss of any individual connection, subject to target-imposed Time2Retain timeout after loss of the LAST connection. =20 Is my understanding correct? Or am I missing something? =20 Thanks in advance, either for confirmation, or for setting me straight. =20 -- Joe Pittman jpittman@netapp.com =20 ------_=_NextPart_001_01C4DD35.0F09769B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I have a question about session = continuation and ErrorRecoveryLevel=3D0
sessions.
 
In short:
  In an = ERL=3D0 session, is=20 a session allowed to persist beyond
  the loss of its last = constituent=20 TCP connection?
 
I think the answer is yes, and = my reasoning=20 is based partly on
text in Section 5.3.6 of RFC3720.  That = section=20 describes
Session Continuation as
 
 "the process by which a = preexisting=20 session continues to be used
  by connection reinstatement... or = by=20 adding a connection
  with a new CID."
 
No mention is made of=20 ErrorRecoveryLevel.  This leads me to think
that as long as the = target=20 supports session continuation in this
case, and as long as the = initiator adds=20 a new connection to the
session in a timely fashion, the session can = survive=20 loss of its
last TCP connection.
 

In general, my = understanding is that,=20 whenever ANY connection is
terminated on an ERL=3D0 session, all = commands=20 allegiant to THAT
connection are immediately terminated = at the=20 target.  But the
session can survive loss of any individual = connection,=20 subject to
target-imposed Time2Retain timeout after loss of the LAST=20 connection.
 

Is my understanding = correct?  Or=20 am I missing something?
 
Thanks in advance, either for = confirmation,=20 or for setting me
straight.
 
--
Joe Pittman
jpittman@netapp.com
=00 ------_=_NextPart_001_01C4DD35.0F09769B-- --===============1650669697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1650669697==-- From ips-bounces@ietf.org Wed Dec 8 12:56:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19432 for ; Wed, 8 Dec 2004 12:56:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc6AN-0003iH-QB for ips-web-archive@ietf.org; Wed, 08 Dec 2004 13:03:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5wi-0008JA-Ha; Wed, 08 Dec 2004 12:49:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5ll-0005X1-TS for ips@megatron.ietf.org; Wed, 08 Dec 2004 12:38:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17090 for ; Wed, 8 Dec 2004 12:38:26 -0500 (EST) Received: from smtp100.rog.mail.re2.yahoo.com ([206.190.36.78]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cc5sY-00030K-Ot for ips@ietf.org; Wed, 08 Dec 2004 12:45:32 -0500 Received: from unknown (HELO Doranto) (BillMurray@rogers.com@65.48.112.58 with login) by smtp100.rog.mail.re2.yahoo.com with SMTP; 8 Dec 2004 17:37:52 -0000 Message-ID: <000d01c4dd4c$e7ff7cb0$6502a8c0@Doranto> From: "BillMurray" To: Date: Wed, 8 Dec 2004 12:39:40 -0500 Organization: Storola MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: [Ips] Distinction between format and protocol error X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: BillMurray List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Sections 6.6 and 6.11 seem to clearly explain what Format and Protocol Errors are and how they are handled. However section 10 seems a bit contradictory (unless reserved areas of the pdu header are not considered fields). How am I to interpret this? Also, what is the difference between 'illegal' and 'inconsistent' in section 6.6 below? 6.6 Format Errors The following two explicit violations of PDU layout rules are format errors: a) Illegal contents of any PDU header field except the Opcode (legal values are specified in Section 10 iSCSI PDU Formats). b) Inconsistent field contents (consistent field contents are specified in Section 10 iSCSI PDU Formats). 10. iSCSI PDU Formats Receipt of reserved code values in defined fields MUST be reported as a protocol error. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Dec 8 19:35:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29650 for ; Wed, 8 Dec 2004 19:35:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcCOT-0006rE-VJ for ips-web-archive@ietf.org; Wed, 08 Dec 2004 19:42:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcCDG-0001hV-Ga; Wed, 08 Dec 2004 19:31:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcC9F-0000Qg-BR for ips@megatron.ietf.org; Wed, 08 Dec 2004 19:27:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29208 for ; Wed, 8 Dec 2004 19:27:05 -0500 (EST) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcCFx-0006iF-Ak for ips@ietf.org; Wed, 08 Dec 2004 19:34:15 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel13.hp.com (Postfix) with ESMTP id ABF161C12B5B for ; Wed, 8 Dec 2004 16:26:51 -0800 (PST) Received: from [127.0.0.1] (palnai12-1291.corp.hp.com [15.244.197.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id 47D608084 for ; Wed, 8 Dec 2004 16:26:51 -0800 (PST) Message-ID: <41B79BC9.6090009@rose.hp.com> Date: Wed, 08 Dec 2004 16:26:49 -0800 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] RE: iSER Open Issues 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: bdc523f9a54890b8a30dd6fd53d5d024 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit > But that is *not* the case at the other end.....selecting "NONE" means you MUST at > least accept these messages from the transport layer at full speed. Let us not mix iSCSI-3720 semantics with what it means for RNICs that don't do graceful handling. iSCSI-3720 places _no_ restrictions on how many unexpected PDUs must be received "at full speed" - the receiving iSCSI layer is allowed to discard an unexpected PDU without any processing and while the PDU is not received, the PDU sits in the transport buffers. The thing I like about a "None" default is that an iSCSI-3720 pair that doesn't negotiate this key works the same way as an iSCSI-3720+iSER pair that chooses not to negotiate. > What the default value is is really not that important Indeed. Also what I said in the DC meeting. Mike's request for list input was what prompted me. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Caitlin Bestler wrote: >>From: "Mallikarjun C." >>Subject: Re: [Ips] iSER Open Issues >> >>IMO, a default of None makes sense since these are >>essentially RFC 3720 semantics (and RFC 3720-compliant >>implementations do not negotiate/understand the new key). >> > > > That is only true from the sending perspective, where "None" > essentially means "don't worry about it", and that does match > TCP semantics. You don't have to worry about overflowing the > target because TCP bottlenecking will efficiently prevent that. > > But that is *not* the case at the other end. Instead of meaning, > "you can read these at whatever pace you want, it will only impact > Performance, not correctness" selecting "NONE" means you MUST at > least accept these messages from the transport layer at full speed. > > I agree with the concern raised at the DC meeting that this is > not an appropriate default. An implementation that does not know > To set the key is probably *not* capable of meeting the requirements > of "NONE", and any capable of doing so would have no problem explicitly > setting the limit. > > That said, explicitly setting the key is not that hard for *anyone*, so > What the default value is is really not that important, as long as it > is defined. > > However, for simplicity of the specification I would recommend that it > either be the minimum or "NONE". That way no third special value is > created. > > > > > -- > Caitlin Bestler > Director Software Architecture > Siliquent Technologies > caitlinb@siliquent.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 From ips-bounces@ietf.org Wed Dec 8 20:16:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02684 for ; Wed, 8 Dec 2004 20:16:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcD2E-0007cT-AA for ips-web-archive@ietf.org; Wed, 08 Dec 2004 20:23:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcCs6-0000SA-VN; Wed, 08 Dec 2004 20:13:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcCj6-0007vv-9P for ips@megatron.ietf.org; Wed, 08 Dec 2004 20:04:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01933 for ; Wed, 8 Dec 2004 20:04:10 -0500 (EST) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcCpw-0007OH-PR for ips@ietf.org; Wed, 08 Dec 2004 20:11:19 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id iB913TDr658916 for ; Wed, 8 Dec 2004 20:03:30 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB913T2j304176 for ; Wed, 8 Dec 2004 18:03:29 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB913Tdi032025 for ; Wed, 8 Dec 2004 18:03:29 -0700 Received: from d03nm115.boulder.ibm.com (d03nm115.boulder.ibm.com [9.17.195.141]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB913ToL032022 for ; Wed, 8 Dec 2004 18:03:29 -0700 In-Reply-To: <41B79BC9.6090009@rose.hp.com> To: ips@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] RE: iSER Open Issues X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: John Hufferd Message-ID: Date: Wed, 8 Dec 2004 17:03:08 -0800 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 12/08/2004 18:03:29, Serialize complete at 12/08/2004 18:03:29 X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 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="===============1765374464==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 This is a multipart message in MIME format. --===============1765374464== Content-Type: multipart/alternative; boundary="=_alternative 0005C02C88256F65_=" This is a multipart message in MIME format. --=_alternative 0005C02C88256F65_= Content-Type: text/plain; charset="US-ASCII" I agree with Mallikarjun, and the logic behind what he says. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Alt Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com "Mallikarjun C." Sent by: ips-bounces@ietf.org 12/08/2004 04:26 PM To ips@ietf.org cc Subject Re: [Ips] RE: iSER Open Issues > But that is *not* the case at the other end.....selecting "NONE" means you MUST at > least accept these messages from the transport layer at full speed. Let us not mix iSCSI-3720 semantics with what it means for RNICs that don't do graceful handling. iSCSI-3720 places _no_ restrictions on how many unexpected PDUs must be received "at full speed" - the receiving iSCSI layer is allowed to discard an unexpected PDU without any processing and while the PDU is not received, the PDU sits in the transport buffers. The thing I like about a "None" default is that an iSCSI-3720 pair that doesn't negotiate this key works the same way as an iSCSI-3720+iSER pair that chooses not to negotiate. > What the default value is is really not that important Indeed. Also what I said in the DC meeting. Mike's request for list input was what prompted me. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Caitlin Bestler wrote: >>From: "Mallikarjun C." >>Subject: Re: [Ips] iSER Open Issues >> >>IMO, a default of None makes sense since these are >>essentially RFC 3720 semantics (and RFC 3720-compliant >>implementations do not negotiate/understand the new key). >> > > > That is only true from the sending perspective, where "None" > essentially means "don't worry about it", and that does match > TCP semantics. You don't have to worry about overflowing the > target because TCP bottlenecking will efficiently prevent that. > > But that is *not* the case at the other end. Instead of meaning, > "you can read these at whatever pace you want, it will only impact > Performance, not correctness" selecting "NONE" means you MUST at > least accept these messages from the transport layer at full speed. > > I agree with the concern raised at the DC meeting that this is > not an appropriate default. An implementation that does not know > To set the key is probably *not* capable of meeting the requirements > of "NONE", and any capable of doing so would have no problem explicitly > setting the limit. > > That said, explicitly setting the key is not that hard for *anyone*, so > What the default value is is really not that important, as long as it > is defined. > > However, for simplicity of the specification I would recommend that it > either be the minimum or "NONE". That way no third special value is > created. > > > > > -- > Caitlin Bestler > Director Software Architecture > Siliquent Technologies > caitlinb@siliquent.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 --=_alternative 0005C02C88256F65_= Content-Type: text/html; charset="US-ASCII"
I agree with Mallikarjun, and the logic behind what he says.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


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

12/08/2004 04:26 PM

To
ips@ietf.org
cc
Subject
Re: [Ips] RE: iSER Open Issues





 > But that is *not* the case at the other end.....selecting "NONE"
means you MUST at
> least accept these messages from the transport layer at full speed.

Let us not mix iSCSI-3720 semantics with what it means for RNICs that
don't do graceful handling.

iSCSI-3720 places _no_ restrictions on how many unexpected PDUs must be
received "at full speed" - the receiving iSCSI layer is allowed to
discard an unexpected PDU without any processing and while the PDU is
not received, the PDU sits in the transport buffers.

The thing I like about a "None" default is that an iSCSI-3720 pair that
doesn't negotiate this key works the same way as an iSCSI-3720+iSER pair
that chooses not to negotiate.

> What the default value is is really not that important

Indeed.  Also what I said in the DC meeting.  Mike's request for list
input was what prompted me.


Mallikarjun

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


Caitlin Bestler wrote:
>>From: "Mallikarjun C." <cbm@rose.hp.com>
>>Subject: Re: [Ips] iSER Open Issues
>>
>>IMO, a default of None makes sense since these are
>>essentially RFC 3720 semantics (and RFC 3720-compliant
>>implementations do not negotiate/understand the new key).
>>
>
>
> That is only true from the sending perspective, where "None"
> essentially means "don't worry about it", and that does match
> TCP semantics. You don't have to worry about overflowing the
> target because TCP bottlenecking will efficiently prevent that.
>
> But that is *not* the case at the other end. Instead of meaning,
> "you can read these at whatever pace you want, it will only impact
> Performance, not correctness" selecting "NONE" means you MUST at
> least accept these messages from the transport layer at full speed.
>
> I agree with the concern raised at the DC meeting that this is
> not an appropriate default. An implementation that does not know
> To set the key is probably *not* capable of meeting the requirements
> of "NONE", and any capable of doing so would have no problem explicitly
> setting the limit.
>
> That said, explicitly setting the key is not that hard for *anyone*, so
> What the default value is is really not that important, as long as it
> is defined.
>
> However, for simplicity of the specification I would recommend that it
> either be the minimum or "NONE". That way no third special value is
> created.
>
>
>
>
> --
> Caitlin Bestler
> Director Software Architecture
> Siliquent Technologies
> caitlinb@siliquent.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
--=_alternative 0005C02C88256F65_=-- --===============1765374464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1765374464==-- From ips-bounces@ietf.org Wed Dec 8 20:25:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03534 for ; Wed, 8 Dec 2004 20:25:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcDAg-0007pc-HA for ips-web-archive@ietf.org; Wed, 08 Dec 2004 20:32:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcCwL-0001hr-9z; Wed, 08 Dec 2004 20:17:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcCs7-0000SH-C0 for ips@megatron.ietf.org; Wed, 08 Dec 2004 20:13:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02417 for ; Wed, 8 Dec 2004 20:13:29 -0500 (EST) Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcCyy-0007Xm-Kj for ips@ietf.org; Wed, 08 Dec 2004 20:20:38 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel7.hp.com (Postfix) with ESMTP id 49F55401F; Wed, 8 Dec 2004 20:13:25 -0500 (EST) Received: from [127.0.0.1] (palnai12-1291.corp.hp.com [15.244.197.11]) by rosemail.rose.hp.com (Postfix) with ESMTP id 626A6804F; Wed, 8 Dec 2004 17:13:24 -0800 (PST) Message-ID: <41B7A6B5.6040309@rose.hp.com> Date: Wed, 08 Dec 2004 17:13:25 -0800 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pittman, Joseph" Subject: Re: [Ips] iSCSI: Session continuation and ERL=0 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: 02ec665d00de228c50c93ed6b5e4fc1a 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Joseph, Your understanding is correct. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Pittman, Joseph wrote: > I have a question about session continuation and ErrorRecoveryLevel=0 > sessions. > > In short: > In an ERL=0 session, is a session allowed to persist beyond > the loss of its last constituent TCP connection? > > I think the answer is yes, and my reasoning is based partly on > text in Section 5.3.6 of RFC3720. That section describes > Session Continuation as > > "the process by which a preexisting session continues to be used > by connection reinstatement... or by adding a connection > with a new CID." > > No mention is made of ErrorRecoveryLevel. This leads me to think > that as long as the target supports session continuation in this > case, and as long as the initiator adds a new connection to the > session in a timely fashion, the session can survive loss of its > last TCP connection. > > > In general, my understanding is that, whenever ANY connection is > terminated on an ERL=0 session, all commands allegiant to THAT > connection are immediately terminated at the target. But the > session can survive loss of any individual connection, subject to > target-imposed Time2Retain timeout after loss of the LAST connection. > > > Is my understanding correct? Or am I missing something? > > Thanks in advance, either for confirmation, or for setting me > straight. > > -- > Joe Pittman > jpittman@netapp.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 From ips-bounces@ietf.org Thu Dec 9 02:36:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27680 for ; Thu, 9 Dec 2004 02:36:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcIxJ-0006gk-Ju for ips-web-archive@ietf.org; Thu, 09 Dec 2004 02:43:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcImf-0008F6-G2; Thu, 09 Dec 2004 02:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcIgX-0004o2-4G for ips@megatron.ietf.org; Thu, 09 Dec 2004 02:25:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27232 for ; Thu, 9 Dec 2004 02:25:56 -0500 (EST) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcInS-0006YM-TI for ips@ietf.org; Thu, 09 Dec 2004 02:33:07 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id C3D632B22D for ; Wed, 8 Dec 2004 23:25:54 -0800 (PST) Received: from [127.0.0.1] (palnai12-442.corp.hp.com [15.244.193.186]) by rosemail.rose.hp.com (Postfix) with ESMTP id 776FA8248 for ; Wed, 8 Dec 2004 23:25:54 -0800 (PST) Message-ID: <41B7FE03.7010402@rose.hp.com> Date: Wed, 08 Dec 2004 23:25:55 -0800 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] Distinction between format and protocol error References: <000d01c4dd4c$e7ff7cb0$6502a8c0@Doranto> In-Reply-To: <000d01c4dd4c$e7ff7cb0$6502a8c0@Doranto> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Please refer to a recent discussion thread: http://www1.ietf.org/mail-archive/web/ips/current/msg01139.html I think it answers your questions. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com BillMurray wrote: > Sections 6.6 and 6.11 seem to clearly explain what > Format and Protocol Errors are and how they are > handled. However section 10 seems a bit contradictory > (unless reserved areas of the pdu header are not > considered fields). > > How am I to interpret this? > > Also, what is the difference between 'illegal' and > 'inconsistent' in section 6.6 below? > > > > 6.6 Format Errors > > The following two explicit violations of PDU layout rules are > format errors: > > a) Illegal contents of any PDU header field except the Opcode > (legal values are specified in Section 10 iSCSI PDU Formats). > b) Inconsistent field contents (consistent field contents are > specified in Section 10 iSCSI PDU Formats). > > > 10. iSCSI PDU Formats > > Receipt of reserved code values in defined fields MUST be reported as a protocol error. > > > > > > > _______________________________________________ > 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 Dec 9 03:46:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02846 for ; Thu, 9 Dec 2004 03:46:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcK3f-0007vo-FV for ips-web-archive@ietf.org; Thu, 09 Dec 2004 03:53:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcJkV-00022g-VM; Thu, 09 Dec 2004 03:34:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcJch-0000e7-SW for ips@megatron.ietf.org; Thu, 09 Dec 2004 03:26:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01543 for ; Thu, 9 Dec 2004 03:26:02 -0500 (EST) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcJje-0007ZW-37 for ips@ietf.org; Thu, 09 Dec 2004 03:33:14 -0500 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 iB98PVug201298 for ; Thu, 9 Dec 2004 08:25:31 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/VER6.6) with ESMTP id iB98Pjep119268 for ; Thu, 9 Dec 2004 09:25:45 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB98PVJd004829 for ; Thu, 9 Dec 2004 09:25:31 +0100 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 iB98PVv5004823; Thu, 9 Dec 2004 09:25:31 +0100 In-Reply-To: <000d01c4dd4c$e7ff7cb0$6502a8c0@Doranto> To: BillMurray Subject: Re: [Ips] Distinction between format and protocol error MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M2_07222004 Beta 2NP July 22, 2004 From: Julian Satran Message-ID: Date: Thu, 9 Dec 2004 10:25:38 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 09/12/2004 10:25:38, Serialize complete at 09/12/2004 10:25:38 X-Spam-Score: 0.5 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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="===============1971618667==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c This is a multipart message in MIME format. --===============1971618667== Content-Type: multipart/alternative; boundary="=_alternative 002B14A5C2256F65_=" This is a multipart message in MIME format. --=_alternative 002B14A5C2256F65_= Content-Type: text/plain; charset="US-ASCII" Bill, What the text meant by illegal - is a field value that is wrong by itself (regardless of the value of other fields) while inconsistent meant with regard to other fields or the general context (e.g., an ITT and LU in response do not match those in a request although both are "legal" in a strict sense and may be even valid in the context). We understand that in general inconsistent is a a particular case of illegal (dictionary definition for illegal is "forbidden by law or statute") Julo "BillMurray" Sent by: ips-bounces@ietf.org 08-12-04 19:39 Please respond to BillMurray To cc Subject [Ips] Distinction between format and protocol error Sections 6.6 and 6.11 seem to clearly explain what Format and Protocol Errors are and how they are handled. However section 10 seems a bit contradictory (unless reserved areas of the pdu header are not considered fields). How am I to interpret this? Also, what is the difference between 'illegal' and 'inconsistent' in section 6.6 below? 6.6 Format Errors The following two explicit violations of PDU layout rules are format errors: a) Illegal contents of any PDU header field except the Opcode (legal values are specified in Section 10 iSCSI PDU Formats). b) Inconsistent field contents (consistent field contents are specified in Section 10 iSCSI PDU Formats). 10. iSCSI PDU Formats Receipt of reserved code values in defined fields MUST be reported as a protocol error. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 002B14A5C2256F65_= Content-Type: text/html; charset="US-ASCII"
Bill,

What the text meant by illegal - is a field value that is wrong by itself (regardless of the value of other fields) while inconsistent meant with regard to other fields or the general context (e.g., an ITT and LU in response do not match those in a request although both are "legal" in a strict sense and may be even valid in the context).

We understand that in general inconsistent is a a particular case of illegal (dictionary definition for illegal is "forbidden by law or statute")

Julo


"BillMurray" <BillMurray@rogers.com>
Sent by: ips-bounces@ietf.org

08-12-04 19:39
Please respond to
BillMurray <BillMurray@rogers.com>
To
<ips@ietf.org>
cc
Subject
[Ips] Distinction between format and protocol error





Sections 6.6 and 6.11 seem to clearly explain what
Format and Protocol Errors are and how they are
handled. However section 10 seems a bit contradictory
(unless reserved areas of the pdu header are not
considered fields).

How am I to interpret this?

Also, what is the difference between 'illegal' and
'inconsistent' in section 6.6 below?



6.6 Format Errors

The following two explicit violations of PDU layout rules are
format errors:

a) Illegal contents of any PDU header field except the Opcode
(legal values are specified in Section 10 iSCSI PDU Formats).
b) Inconsistent field contents (consistent field contents are
specified in Section 10 iSCSI PDU Formats).


10. iSCSI PDU Formats

Receipt of reserved code values in defined fields MUST be reported as a protocol error.






_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 002B14A5C2256F65_=-- --===============1971618667== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1971618667==-- From ips-bounces@ietf.org Thu Dec 9 13:32:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19161 for ; Thu, 9 Dec 2004 13:32:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcTCD-0003RV-2o for ips-web-archive@ietf.org; Thu, 09 Dec 2004 13:39:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcSsD-0000aC-Pp; Thu, 09 Dec 2004 13:18:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcSlV-00075q-PE for ips@megatron.ietf.org; Thu, 09 Dec 2004 13:11:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17250 for ; Thu, 9 Dec 2004 13:11:42 -0500 (EST) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcSsN-00030t-0J for ips@ietf.org; Thu, 09 Dec 2004 13:19:01 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id DBBE35BD for ; Thu, 9 Dec 2004 13:11:33 -0500 (EST) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.45.109]) by rosemail.rose.hp.com (Postfix) with ESMTP id 9803F835D for ; Thu, 9 Dec 2004 10:11:33 -0800 (PST) Message-ID: <41B89558.9040806@rose.hp.com> Date: Thu, 09 Dec 2004 10:11:36 -0800 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] iSCSI: Session continuation and ERL=0 References: <41B7A6B5.6040309@rose.hp.com> In-Reply-To: <41B7A6B5.6040309@rose.hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Two follow-up comments. >But the >> session can survive loss of any individual connection, subject to >> target-imposed Time2Retain timeout after loss of the LAST connection. - Note that it's actually Time2Retain after the initial respite time - i.e. (Time2Wait+Time2Retain) in all. The spec is clear on this in 12.15, but 12.16 unfortunately is a bit less clear. - Someone had pointed out to me offline that "session can survive" might be taken to mean "session along with the tasks". Just to be clear on the list, the tasks do not survive in level 0 operation, it is just the I_T nexus that survives, post-continuation. This may be of questionable value to some configurations (and thus can be disabled via zero-valued timers), while some may like it for its value in avoiding SCSI-level clearing effects. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Mallikarjun C. wrote: > Joseph, > > Your understanding is correct. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > Pittman, Joseph wrote: > >> I have a question about session continuation and ErrorRecoveryLevel=0 >> sessions. >> >> In short: >> In an ERL=0 session, is a session allowed to persist beyond >> the loss of its last constituent TCP connection? >> >> I think the answer is yes, and my reasoning is based partly on >> text in Section 5.3.6 of RFC3720. That section describes >> Session Continuation as >> >> "the process by which a preexisting session continues to be used >> by connection reinstatement... or by adding a connection >> with a new CID." >> >> No mention is made of ErrorRecoveryLevel. This leads me to think >> that as long as the target supports session continuation in this >> case, and as long as the initiator adds a new connection to the >> session in a timely fashion, the session can survive loss of its >> last TCP connection. >> >> >> In general, my understanding is that, whenever ANY connection is >> terminated on an ERL=0 session, all commands allegiant to THAT >> connection are immediately terminated at the target. But the >> session can survive loss of any individual connection, subject to >> target-imposed Time2Retain timeout after loss of the LAST connection. >> >> >> Is my understanding correct? Or am I missing something? >> >> Thanks in advance, either for confirmation, or for setting me >> straight. >> >> -- >> Joe Pittman >> jpittman@netapp.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 Dec 9 15:08:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28322 for ; Thu, 9 Dec 2004 15:08:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcUhT-0005ip-Uj for ips-web-archive@ietf.org; Thu, 09 Dec 2004 15:15:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcUTv-0004R1-O0; Thu, 09 Dec 2004 15:01:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcUQd-0000rP-Lr for ips@megatron.ietf.org; Thu, 09 Dec 2004 14:58:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26855 for ; Thu, 9 Dec 2004 14:58:17 -0500 (EST) Received: from fep2.012.net.il ([212.117.129.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcUXf-0005Rw-9E for ips@ietf.org; Thu, 09 Dec 2004 15:05:36 -0500 Received: from [192.168.0.100] ([80.179.57.205]) by fep2.012.net.il with ESMTP id <20041209195735.DLZV9868.fep2@[80.179.57.205]>; Thu, 9 Dec 2004 21:57:35 +0200 Message-ID: <41B8AE27.3030508@haifasphere.co.il> Date: Thu, 09 Dec 2004 21:57:27 +0200 From: Julian Satran User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: BillMurray Subject: Re: [Ips] Distinction between format and protocol error References: <000d01c4dd4c$e7ff7cb0$6502a8c0@Doranto> In-Reply-To: <000d01c4dd4c$e7ff7cb0$6502a8c0@Doranto> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Bill, What the text meant by illegal - is a field value that is wrong by itself (regardless of the value of other fields) while inconsistent meant with regard to other fields or the general context (e.g., an ITT and LU in response do not match those in a request although both are "legal" in a strict sense and may be even valid in the context). We understand that in general inconsistent is a a particular case of illegal (dictionary definition for illegal is "forbidden by law or statute") Julo BillMurray wrote: >Sections 6.6 and 6.11 seem to clearly explain what >Format and Protocol Errors are and how they are >handled. However section 10 seems a bit contradictory >(unless reserved areas of the pdu header are not >considered fields). > >How am I to interpret this? > >Also, what is the difference between 'illegal' and >'inconsistent' in section 6.6 below? > > > >6.6 Format Errors > >The following two explicit violations of PDU layout rules are >format errors: > >a) Illegal contents of any PDU header field except the Opcode >(legal values are specified in Section 10 iSCSI PDU Formats). >b) Inconsistent field contents (consistent field contents are >specified in Section 10 iSCSI PDU Formats). > > >10. iSCSI PDU Formats > >Receipt of reserved code values in defined fields MUST be reported as a protocol error. > > > > > > >_______________________________________________ >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 Dec 9 16:34:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10664 for ; Thu, 9 Dec 2004 16:34:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcW38-0000mI-DN for ips-web-archive@ietf.org; Thu, 09 Dec 2004 16:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcVM6-0004sD-AS; Thu, 09 Dec 2004 15:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcV9i-00070n-T0; Thu, 09 Dec 2004 15:44:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02522; Thu, 9 Dec 2004 15:44:53 -0500 (EST) Message-Id: <200412092044.PAA02522@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 09 Dec 2004 15:44:53 -0500 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-fcip-mib-07.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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --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 : Definition of Managed Objects for FCIP Author(s) : R. Natarajan, A. Rijhsinghani Filename : draft-ietf-ips-fcip-mib-07.txt Pages : 32 Date : 2004-12-9 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing FCIP entities, which are used to interconnect FC fabrics with IP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-mib-07.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-fcip-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcip-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-9155922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-9155922.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Mon Dec 20 16:37:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11478 for ; Mon, 20 Dec 2004 16:37:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgVMq-0005tK-HD for ips-web-archive@ietf.org; Mon, 20 Dec 2004 16:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgUsR-0006mm-46; Mon, 20 Dec 2004 16:15:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgUX1-0002zj-1W; Mon, 20 Dec 2004 15:53:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03499; Mon, 20 Dec 2004 15:53:24 -0500 (EST) Message-Id: <200412202053.PAA03499@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 20 Dec 2004 15:53:24 -0500 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-fcmgmt-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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --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 : Fibre Channel Management MIB Author(s) : K. McCloghrie Filename : draft-ietf-ips-fcmgmt-mib-06.txt Pages : 79 Date : 2004-12-20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for informantion related to Fibre Channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-06.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-fcmgmt-mib-06.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-fcmgmt-mib-06.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: <2004-12-20154859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcmgmt-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcmgmt-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-20154859.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart--