From owner-ips@ece.cmu.edu Fri Jun 1 00:22:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16211 for ; Fri, 1 Jun 2001 00:22:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f512WHu15942 for ips-outgoing; Thu, 31 May 2001 22:32:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from homa.asicdesigners.com (ip-64-63-65-105.reverse.mobilenetics.com [64.63.65.105] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f512WFt15937 for ; Thu, 31 May 2001 22:32:16 -0400 (EDT) Received: from homa.asicdesigners.com ([10.1.1.5]) by homa.asicdesigners.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 May 2001 19:31:02 -0700 Received: by homa.asicdesigners.com (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG05312001-193057-44.MMD@asicdesigners.com; Thu, 31 May 2001 19:30:57 -0700 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by mail14.netservers.net (8.9.3/8.9.3) with ESMTP id TAA26206 for ; Thu, 31 May 2001 19:27:44 -0700 Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f510MtZ07213 for ips-outgoing; Thu, 31 May 2001 20:22:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from internaut.com ([64.38.134.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f510Mrt07208 for ; Thu, 31 May 2001 20:22:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id RAA52985; Thu, 31 May 2001 17:12:30 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 31 May 2001 17:12:30 -0700 (PDT) From: Bernard Aboba To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: Re: iSCSI Security mechanisms In-Reply-To: <0F31E5C394DAD311B60C00E029101A070801563E@corpmx9.isus.emc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: fff3354e07519e52020679e11e8bed37 Status: RO X-OriginalArrivalTime: 01 Jun 2001 02:31:02.0390 (UTC) FILETIME=[E698F960:01C0EA42] Sender: owner-ips@ece.cmu.edu Precedence: bulk > This leaves open the issue of where the key(s) for > ESP come from. IKE is OPTIONAL, and use of SRP to > supply keys for ESP is NOT REQUIRED (not even > specified - I need to find the time to work on > writing this up). This leaves pre-shared keys as > the minimum mechanism, and hence I believe that > a suitably secured administrative interface to > supply pre-shared keys to ESP will have to be > REQUIRED for interoperability even if a dynamic > keying mechanism like IKE is implemented. > Let me make sure I understand this: a. You use SRP (which derives a key) only for authentication, but then throw the derived keying material away. b. You then use IPSEC manual keying, along with an unspecified transform, and key distribution mechanism. Note that what is described above is not really pre-shared secrets, because those are used to authenticate DH in order to derive keying material. Since you're not using derived keying material, we're really talking about manual keying. I would suggest that the above manages to combine the computational demands of IKE (and then some, since SRP is slower than ordinary DH) the administrative headaches of manual keying and the interoperability problems of specifying nothing. Ancient proverb: "The first step in removing yourself from a deep hole is to stop digging." If you're going to do SRP for authentication, you might as well add in key derivation, and negotiation of things like ciphersuites, prime modulus/generator groups, etc. so you can use it for IPSEC keying. A rather small spec could accomplish this IF we decide it is necessary. If don't want to use the SRP keying material, you might as well use a slimmed down version of IKE (say, aggressive mode only) to address the code size concern. From owner-ips@ece.cmu.edu Fri Jun 1 01:41:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18953 for ; Fri, 1 Jun 2001 01:41:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f513auo20370 for ips-outgoing; Thu, 31 May 2001 23:36:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f513ast20366 for ; Thu, 31 May 2001 23:36:54 -0400 (EDT) Received: (cpmta 3196 invoked from network); 31 May 2001 20:36:48 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO ljoy) (63.202.160.80) by smtp.telocity.com (209.228.33.206) with SMTP; 31 May 2001 20:36:48 -0700 X-Sent: 1 Jun 2001 03:36:48 GMT From: "Douglas Otis" To: "Glen Turner" , Cc: Subject: RE: More on iSCSI boot Date: Thu, 31 May 2001 20:34:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B16F5CC.5E7C6B31@aarnet.edu.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen, You are making several assumptions as to what exists on each machine by assuming a new boot protocol may be available in PROM. You are also assuming which arguments this new protocol will need as it becomes developed and that this protocol can depend on overlaid DHCP settings. Can DHCP securely support both an iSCSI and TFTP boot process? Here you will run into not only the problem of initially setting shared secrets but also updating this new boot protocol as it matures. The angst the shared secret causes should pale in comparison to maintaining a complex version 1 boot protocol. Two ways to do the same thing should suggest this optional iSCSI approach is not a good one. If just one is to be used, it can not be an initial iSCSI boot. In that case, there is no need to muck with DHCP or change how the initial boot image is obtained. Start your scenario at step two. Once at step two, I would highly recommend something be used that is more robust that SLP or DHCP for management. Doug > Black_David@emc.com wrote: > > > > David Robinson's messages support my inclination to reuse > > DHCP option 17 (Root Path) by defining iSCSI syntax > > for it. > > The "root path" is still useful if the image > has been loaded using iSCSI or TFTP. > > An alternative would be to request an option for > "image load protocol" and redefine DHCP's "sname" > and "file" and options 66 "Server name" and option > 67 "bootfile name" for interpretation with iSCSI. > > Without an allocated option, it might be possible > to simply redefine the sname/66 and file/67 so > that sname/66 beginning with "iscsi:" defines > the iSCSI boot method. > > > GENERAL COMMENTS ON DRAFT-02 > > I'm not at all keen on the mechanism in draft-*-boot-02. > The DHCP option should be more generic, as in > > : > > and defined for iSCSI as > > iscsi:[:[:[:[:]]]] > > This would limit future options growth. > > Even better would be to define a DHCP option "boot protocol" > and reuse the sname/66 and file/67 fields. In the absence > of the "boot protocol" option TFTP would be assumed. > > Other issues with the draft: > > - if is a domain name then > - the "name server" DHCP option SHOULD > be provided > - SHOULD be a FQDN unless > the "domain name" option DHCP option > is provided > > - may be better to be textual, as > this allows variants on TCP (such as framing). > Default value is "tcp" with "tcp-*", "udp" and > "sctp" intended for future use. Syntax is: > > ::= > ::= > ::= > ::= > ::= > ::= > ::= - | . > ::= a | b | ... | z > > The syntax of all textual options should be defined using > IETF BNF rather than in the text. > > - The "LUN" field is a 16 byte hexadecimal > representation of the 8-byte LU number in hex. > > does not allow for SCSI to redefine or expand > the LUN. Although this is unlikely, I'd suggest > text like: > > is the SCSI logical unit number in hexadecimal. > The syntax is: > > ::= > ::= > ::= > ::= 0 | 1 | ... | 9 | A | B | ... | F | a | b | ... | f > ::= | > > If you do want a fixed-length field, then using BNF > can replace the somewhat unwieldy text > > ::= : | > ::= > ::= > ::= 0 | 1 | ... | 9 | A | B | ... | F | a | b | ... | f > > -- > Glen Turner Network Engineer > (08) 8303 3936 Australian Academic and Research Network > glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ > -- > The revolution will not be televised, it will be digitised > From owner-ips@ece.cmu.edu Fri Jun 1 09:52:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08368 for ; Fri, 1 Jun 2001 09:52:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f51C6i302869 for ips-outgoing; Fri, 1 Jun 2001 08:06:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f51C6gt02864 for ; Fri, 1 Jun 2001 08:06:43 -0400 (EDT) Received: from daniel ([213.10.179.111]) by smtp01.wxs.nl (Netscape Messaging Server 4.05) with SMTP id GE92YZ02.HP8; Fri, 1 Jun 2001 14:06:35 +0200 Message-ID: <006501c0ea94$45439410$9600000a@daniel> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: , Subject: iscsi: out of order unsolicited data Date: Fri, 1 Jun 2001 14:13:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C0EAA5.0856BEE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C0EAA5.0856BEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Page 17 of iscsi rev6 draft says Unsolicited data MUST be sent on every connection in the same order in = which commands were sent. A target receiveing data out of order SHOULD = termintate the session My question is if the PDU was delivered in correct order from initiator = but not received in correct order by target because it got missed = somewhere in the path, shouldn't the target wait for retransmission = instead of terminating the session. Regards, Sanjeev ------=_NextPart_000_0062_01C0EAA5.0856BEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
Page 17 of iscsi rev6 draft = says
 
Unsolicited data MUST be sent on every = connection=20 in the same order in which commands were sent. A target receiveing data = out of=20 order SHOULD termintate the session
 
My question is if the PDU was delivered = in correct=20 order from initiator but not received in correct order by target because = it got=20 missed somewhere in the path, shouldn't the target wait for = retransmission=20 instead of terminating the session.
 
Regards,
Sanjeev
------=_NextPart_000_0062_01C0EAA5.0856BEE0-- From owner-ips@ece.cmu.edu Fri Jun 1 09:57:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08433 for ; Fri, 1 Jun 2001 09:57:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f51Barv00931 for ips-outgoing; Fri, 1 Jun 2001 07:36:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tiny-teddy.aarnet.edu.au (IDENT:root@tiny-teddy.aarnet.edu.au [203.21.37.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f516nLt02693 for ; Fri, 1 Jun 2001 02:49:21 -0400 (EDT) Received: from aarnet.edu.au (gt1.aarnet.adelaide.edu.au [129.127.180.236]) by tiny-teddy.aarnet.edu.au (8.11.0/8.11.0) with ESMTP id f516mFX03880; Fri, 1 Jun 2001 16:18:15 +0930 Message-ID: <3B173AAA.86B73795@aarnet.edu.au> Date: Fri, 01 Jun 2001 16:18:10 +0930 From: Glen Turner Organization: Australian Academic and Research Network X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-ac11-mpls0.990-gdt1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Douglas Otis CC: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: More on iSCSI boot References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > You are making several assumptions as to what exists on each machine by > assuming a new boot protocol may be available in PROM. Naturally. It's a new protocol, so sysadms may choose to upgrade flash BIOSes or purchase new PROMS. Or they may choose not to. > Can DHCP securely support both an iSCSI and TFTP boot process? DHCP can't even securely support a TFTP boot as it stands today. That's not IPS's problem. IPS's responsibility is to ensure than when a secure DHCP is developed, any IPS protocol used in the boot process then allows an end-to-end secure boot. > Here you will run into not only the problem of initially setting > shared secrets Not a protocol problem, a vendor problem. For example, there is nothing to prevent vendors from reading the secret from the network, or a floppy disk or a PC Card keyloader when asked to do so from the BIOS configuration. Again, not IPS's problem. > Two ways to do the same thing should suggest this optional iSCSI > approach is not a good one. If just one is to be used, it can not be an > initial iSCSI boot. I can't agree. TFTP and iSCSI appeal to differing market segments. Enterprises will have significant robust iSCSI storage, engineered for serious uptime. That in turn makes it cheap to use iSCSI boot to obtain a boot image rather than implement a set of TFTP servers that won't offer the same availability. Similarly, high threat environments like universities are attracted to iSCSI boot because the boot image can be held on a iSCSI CD drive, requiring physical access or hacked routers for students to subvert the network boot process. The large group in the middle will probably be happy to continue to boot from attached disk with its higher per-unit sysadm costs, with small workgroups using TFTP becuase of its ubiquity. If you want to criticise the iSCSI boot proposal, then how about pointing out that iSCSI boot doesn't exploit the expected availability of an iSCSI network by defining further boot devices should the first device be unavailable. Now doing that using DHCP gets problematic... Regards, Glen From owner-ips@ece.cmu.edu Fri Jun 1 11:16:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09622 for ; Fri, 1 Jun 2001 11:16:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f51DDcD10830 for ips-outgoing; Fri, 1 Jun 2001 09:13:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f51DDbg10826 for ; Fri, 1 Jun 2001 09:13:37 -0400 (EDT) Received: from cs.uchicago.edu ([24.91.85.185]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f51DDW813420 for ; Fri, 1 Jun 2001 09:13:36 -0400 (EDT) Message-Id: <200106011313.f51DDW813420@chmls06.mediaone.net> To: ips@ece.cmu.edu Subject: Re: More on iSCSI boot In-Reply-To: Message from "John Hufferd" of "Fri, 01 Jun 2001 00:12:25 PDT." References: Date: Fri, 01 Jun 2001 09:11:24 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk > I am sure that the Draft needs some polishing, but I think its fundamental > approach is fine. OK. Steph From owner-ips@ece.cmu.edu Fri Jun 1 14:29:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15621 for ; Fri, 1 Jun 2001 14:29:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f51HQdb01260 for ips-outgoing; Fri, 1 Jun 2001 13:26:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f51HQbg01256 for ; Fri, 1 Jun 2001 13:26:37 -0400 (EDT) Received: (cpmta 9808 invoked from network); 1 Jun 2001 10:26:31 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO ljoy) (63.202.160.80) by smtp.telocity.com (209.228.33.217) with SMTP; 1 Jun 2001 10:26:31 -0700 X-Sent: 1 Jun 2001 17:26:31 GMT From: "Douglas Otis" To: "Glen Turner" Cc: , Subject: RE: More on iSCSI boot Date: Fri, 1 Jun 2001 10:24:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3B173AAA.86B73795@aarnet.edu.au> Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen, Regardless how robust you imagine iSCSI to be or become, it is of several orders of greater complexity than TFTP or MTFTP, the preferred method of obtaining a network boot image. The initial concern being kicked around on this thread was over the fact that each machine in a large enterprise would need to be visited to initialize it with a shared secret for a secure boot if diskless. Trivial File Transfer Protocol is just that, trivial. It is well understood, can work within a slow and clumsy kernel, and can obtain a secure initial boot image. Use that boot image to then launch iSCSI. If you wish to include any option, use an existing professional management tool combined with this initial boot image. I see no reason to alter DHCP and I would discourage the concept of using iSCSI for the initial boot in an enterprise environment. The advantage should be obvious. Upgrades to this initial boot image is possible without the need to revisit each machine. The concern that this then requires DHCP and TFTP network services for a boot to occur should be weighed against the expense of updating each machine as iSCSI matures. In addition, as there is already a means to network boot, using the existing standard provides an immediate solution that is stable and understood. You would not need to manage multiple methods for obtaining this initial boot image. A mode that captures this boot image where it is replayed until it is rejected may provide better performance and make everyone happy as the results would look the same. Moving from direct attached drives should warrant this additional consideration. It should always be possible to set various defaults where no intervention is needed to get the SCSI stack running into a boot device. This should be possible for consumer items. In which case even DHCP may not be available. That is a different problem all together. Here you expect to manage everything locally. A floppy or CD may be used to create this self-contained environment. In this environment, DHCP is not likely configurable to provide all the fun stuff being imagined. Here you have a need to get the code working through manual settings. There is no justification to modify DHCP that I can see. Doug From owner-ips@ece.cmu.edu Fri Jun 1 14:29:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15635 for ; Fri, 1 Jun 2001 14:29:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f51GOrm26278 for ips-outgoing; Fri, 1 Jun 2001 12:24:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f51GOpg26274 for ; Fri, 1 Jun 2001 12:24:51 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA202568 for ; Fri, 1 Jun 2001 18:24:30 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.96) with SMTP id SAA19570 for ; Fri, 1 Jun 2001 18:24:30 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A5E.005A0CF4 ; Fri, 1 Jun 2001 18:23:35 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Fri, 1 Jun 2001 15:59:45 +0300 Subject: Re: iSCSI rev. 7 status Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Really soon (3-4 weeks at most perhaps even earlier). Julo Chuck Micalizzi on 01-06-2001 00:47:36 Please respond to Chuck Micalizzi To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI rev. 7 status Julian, Do you expect to be posting version 7 anytime soon? thanks chuck From owner-ips@ece.cmu.edu Fri Jun 1 14:32:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15725 for ; Fri, 1 Jun 2001 14:32:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f51H2mY29281 for ips-outgoing; Fri, 1 Jun 2001 13:02:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f51H2kg29275 for ; Fri, 1 Jun 2001 13:02:46 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Fri Jun 1 12:58:30 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Fri Jun 1 13:01:39 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id NAA28021; Fri, 1 Jun 2001 13:01:13 -0400 (EDT) Date: Fri, 1 Jun 2001 13:01:13 -0400 (EDT) Message-Id: <200106011701.NAA28021@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: julian_satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI rev. 7 status Sender: owner-ips@ece.cmu.edu Precedence: bulk would this include an updated error recovery section ? -Sandeep > Really soon (3-4 weeks at most perhaps even earlier). > > Julo > > Chuck Micalizzi on 01-06-2001 00:47:36 > > Please respond to Chuck Micalizzi > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: iSCSI rev. 7 status > > > > > Julian, > > Do you expect to be posting version 7 anytime soon? > > thanks > > chuck > From owner-ips@ece.cmu.edu Fri Jun 1 20:19:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19756 for ; Fri, 1 Jun 2001 20:19:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f51MPJv26759 for ips-outgoing; Fri, 1 Jun 2001 18:25:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f51MPHg26753 for ; Fri, 1 Jun 2001 18:25:17 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 18:25:11 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0708015649@corpmx9.isus.emc.com> From: Black_David@emc.com To: aboba@internaut.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Security mechanisms Date: Fri, 1 Jun 2001 18:25:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, I think this is an instance of brilliant minds thinking alike (or at least along parallel tracks) With the exception of your final paragraph, your comments have reproduced much of the rationale from the interim meeting for wanting to use SRP for ESP keying. I apologize for the lack of detail in the minutes that lead you to have to reproduce this - it's hard to take good minutes and actively participate in the discussion at the same time. I guess this is a backhanded confirmation that using SRP to key ESP is digging in a useful place :-). iSCSI already has sufficient negotiation support to handle selection of prime/modulus, etc., provided that one is careful about how it's used (the negotiation is not authenticated/protected in the fashion that IKE's is). There are multiple concerns about IKE. In addition to code size, there's a concern that the iSCSI identities that need to be authenticated (Node Names) are both foreign to IKE and have a greater span (i.e., IKE is not end-to-end wrt iSCSI because the identities of multiple iSCSI nodes that share a single pair can't be distinguished below the iSCSI layer). There's also a need for SRP by itself to be usable for inband authentication when/where ESP is not used (my mechanism summary email was about what MUST/SHOULD/MAY be implemented -- what MUST/SHOULD/MAY be used is a separate, but related, issue) - IKE is not a good fit for this sort of authentication. iSCSI does have to specify the ESP authentication/integrity transform - as things currently stand, a SHA-1 HMAC (RFC 2404 specifies HMAC-SHA-1-96) would be a likely choice, but an alternate could be an AES-related MAC if it's specification will be available in a suitable timeframe. I'll correct my usage of "manual" vs. "pre-shared" keys in the future - thanks for the clarification. Thanks, --David > -----Original Message----- > From: Bernard Aboba [SMTP:aboba@internaut.com] > Sent: Thursday, May 31, 2001 8:13 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI Security mechanisms > > > This leaves open the issue of where the key(s) for > > ESP come from. IKE is OPTIONAL, and use of SRP to > > supply keys for ESP is NOT REQUIRED (not even > > specified - I need to find the time to work on > > writing this up). This leaves pre-shared keys as > > the minimum mechanism, and hence I believe that > > a suitably secured administrative interface to > > supply pre-shared keys to ESP will have to be > > REQUIRED for interoperability even if a dynamic > > keying mechanism like IKE is implemented. > > > Let me make sure I understand this: > > a. You use SRP (which derives a key) only for authentication, but then > throw the derived keying material away. > > b. You then use IPSEC manual keying, along with an unspecified > transform, and key distribution mechanism. > > Note that what is described above is not really pre-shared secrets, > because those are used to authenticate DH in order to derive keying > material. Since you're not using derived keying material, we're really > talking about manual keying. > > I would suggest that the above manages to combine the computational > demands of IKE (and then some, since SRP is slower than ordinary DH) > the administrative headaches of manual keying and the interoperability > problems of specifying nothing. > > Ancient proverb: "The first step in removing yourself from a deep hole is > to stop digging." > > If you're going to do SRP for authentication, you might as well add in key > derivation, and negotiation of things like ciphersuites, prime > modulus/generator groups, etc. so you can use it for IPSEC keying. > A rather small spec could accomplish this IF we decide it is necessary. > > If don't want to use the SRP keying material, you might as well use a > slimmed down version of IKE (say, aggressive mode only) to address the > code size concern. > From owner-ips@ece.cmu.edu Fri Jun 1 20:19:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19767 for ; Fri, 1 Jun 2001 20:19:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f51MokU28455 for ips-outgoing; Fri, 1 Jun 2001 18:50:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from spdmraab.compuserve.com (ds-img-rel-2.compuserve.com [149.174.206.155]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f51Mohg28443 for ; Fri, 1 Jun 2001 18:50:43 -0400 (EDT) Received: (from mailgate@localhost) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id SAA00921 for ips@ece.cmu.edu; Fri, 1 Jun 2001 18:50:37 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkw-vty47.as.wcom.net [216.192.232.47]) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id SAA00902; Fri, 1 Jun 2001 18:50:36 -0400 (EDT) Message-ID: <3B181D2F.DF336D37@compuserve.com> Date: Fri, 01 Jun 2001 17:54:39 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "T10, Reflector" , IPS Reflector Subject: SAM-2 w/ multiple ports Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The SAM-2 revision with George's multiple ports proposal incorporated is available at: ftp://ftp.t10.org/t10/drafts/sam2/sam2r18.pdf FYI Ralph... From owner-ips@ece.cmu.edu Fri Jun 1 22:42:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23851 for ; Fri, 1 Jun 2001 22:42:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f520qKZ05777 for ips-outgoing; Fri, 1 Jun 2001 20:52:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from internaut.com ([64.38.134.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f520qJg05773 for ; Fri, 1 Jun 2001 20:52:19 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id RAA54576; Fri, 1 Jun 2001 17:41:26 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 1 Jun 2001 17:41:26 -0700 (PDT) From: Bernard Aboba To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: RE: iSCSI Security mechanisms In-Reply-To: <0F31E5C394DAD311B60C00E029101A0708015649@corpmx9.isus.emc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > the negotiation is not > authenticated/protected in the fashion that > IKE's is). This is easy to fix. Just include the chosen groups/ciphersuites, etc. in the authentication hash. Also remember to generate sufficient keying material (auth & encryption keys, different in each direction). One other thing to think about is whether you will have multiple associations between two endpoints; if so, then you probably want something akin to IKE phase 1/phase 2; if not, you can live with only a phase 1 equivalent. In either case, re-key support is probably needed to avoid staleness in keying material. > iSCSI does have to specify the ESP authentication/integrity > transform - as things currently stand, a SHA-1 HMAC > (RFC 2404 specifies HMAC-SHA-1-96) would be a likely > choice, but an alternate could be an AES-related MAC if > it's specification will be available in a suitable timeframe. Before making a choice, you probably want to examine the performance data. There has been some concern about auth/integrity performance at 10 Gbps, and so some newer integrity mechanisms (e.g. UMAC, as little as 2 cycles/octet) may be appropriate. In general, it's pretty simple to add ciphersuite negotiation to SRP, so you won't be stuck with fixed transforms. From owner-ips@ece.cmu.edu Sat Jun 2 01:44:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27105 for ; Sat, 2 Jun 2001 01:44:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f523iv915403 for ips-outgoing; Fri, 1 Jun 2001 23:44:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mms2.broadcom.com (mms2.broadcom.com [63.70.210.59]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f523itg15398 for ; Fri, 1 Jun 2001 23:44:55 -0400 (EDT) Received: from 63.70.210.33 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Fri, 01 Jun 2001 20:44:53 -0700 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id UAA16541; Fri, 1 Jun 2001 20:44:53 -0700 (PDT) Received: from ltjtardo (dhcpe2-sj1-108 [10.16.75.108]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id UAA04430; Fri, 1 Jun 2001 20:44:53 -0700 (PDT) From: "Joseph Tardo" To: "Bernard Aboba" , Black_David@emc.com cc: ips@ece.cmu.edu Subject: RE: iSCSI Security mechanisms Date: Fri, 1 Jun 2001 20:44:53 -0700 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-WSS-ID: 1706BEBF36860-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David: Let me mention a few other things to bear in mind while considering tossing out IKE and replacing it with some as yet unbaked SRP-based keying scheme. I've been trying to follow the exchanges and have not seen these points raised, but please excuse the posting if I missed a couple. It is very awkward to manage replay sequence number detection with manually keyed IPsec associations. Basically, you have to manually assign the SPI's that go with them as well. IKE provides an exchange of SPI and address values along with establishing keys. Hence it makes it fairly easy to create and re-create security multiple associations, all with replay sequences starting from zero and dynamically assigned SPI's. So, you wouldn't have to just add ciphersuite negotiation to SRP, you would have to add other stuff like SPI and address values, too, maybe more. Interoperable re-keying without dropping packets has proven to be pretty tricky to get right, after many bakeoffs, but most implementations now do, and the most useful technique involves synchronizing the switch over with the IKE phase 2 exchange. It might really be quicker to define a profile for IKE to use the identities you want, even if it means registering a new identity type or providing some scheme for using ID_KEY_ID, aggressive mode, and things like that, rather than invent a whole new securiy protocol (and get it past the security police). --Joe -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Bernard Aboba Sent: Friday, June 01, 2001 5:41 PM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Security mechanisms > the negotiation is not > authenticated/protected in the fashion that > IKE's is). This is easy to fix. Just include the chosen groups/ciphersuites, etc. in the authentication hash. Also remember to generate sufficient keying material (auth & encryption keys, different in each direction). One other thing to think about is whether you will have multiple associations between two endpoints; if so, then you probably want something akin to IKE phase 1/phase 2; if not, you can live with only a phase 1 equivalent. In either case, re-key support is probably needed to avoid staleness in keying material. > iSCSI does have to specify the ESP authentication/integrity > transform - as things currently stand, a SHA-1 HMAC > (RFC 2404 specifies HMAC-SHA-1-96) would be a likely > choice, but an alternate could be an AES-related MAC if > it's specification will be available in a suitable timeframe. Before making a choice, you probably want to examine the performance data. There has been some concern about auth/integrity performance at 10 Gbps, and so some newer integrity mechanisms (e.g. UMAC, as little as 2 cycles/octet) may be appropriate. In general, it's pretty simple to add ciphersuite negotiation to SRP, so you won't be stuck with fixed transforms. From owner-ips@ece.cmu.edu Sat Jun 2 04:09:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10084 for ; Sat, 2 Jun 2001 04:09:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f526EO423444 for ips-outgoing; Sat, 2 Jun 2001 02:14:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from internaut.com ([64.38.134.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f526EMg23440 for ; Sat, 2 Jun 2001 02:14:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA54846; Fri, 1 Jun 2001 23:04:09 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 1 Jun 2001 23:04:09 -0700 (PDT) From: Bernard Aboba To: Joseph Tardo cc: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI Security mechanisms In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > So, you wouldn't have to just add ciphersuite negotiation to SRP, you would > have to add other stuff like SPI and address values, too, maybe more. > Interoperable re-keying without dropping packets has proven to be pretty > tricky to get right, after many bakeoffs, but most implementations now do, > and the most useful technique involves synchronizing the switch over with > the IKE phase 2 exchange. The point I was trying to make was that once you really look at the requirements, you end up adding back many of the features of IKE one by one. Now you might be able to make some simplifications in the process, but the end result will probably end up looking very much like an "IKE profile" as you suggest, with SRP substituted for the DH with shared secret auth under aggressive mode. This might satisfy some requirements that aggressive mode doesn't (such as the ability to avoid cleartext storage of the shared-secret) but it won't be much simpler (or more mature) than an IKE profile. In fact, if you were to compare the two approaches, they'd probably differ from each other in only one or two payloads. > > It might really be quicker to define a profile for IKE to use the identities > you want, even if it means registering a new identity type or providing some > scheme for using ID_KEY_ID, aggressive mode, and things like that, rather > than invent a whole new securiy protocol (and get it past the security > police). All in all, I do think that an IKE profile would be quicker, assuming that this meets the (not yet well articulated) requirements. From owner-ips@ece.cmu.edu Sat Jun 2 16:30:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13421 for ; Sat, 2 Jun 2001 16:30:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f52Id0g04246 for ips-outgoing; Sat, 2 Jun 2001 14:39:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f52Icwg04238 for ; Sat, 2 Jun 2001 14:38:58 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA182532 for ; Sat, 2 Jun 2001 20:38:52 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.96) with SMTP id UAA33022 for ; Sat, 2 Jun 2001 20:38:52 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A5F.00665A62 ; Sat, 2 Jun 2001 20:37:58 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sat, 2 Jun 2001 21:32:05 +0300 Subject: Re: iSCSI rev. 7 status Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk yes - Julo sandeepj@research.bell-labs.com (Sandeep Joshi) on 01-06-2001 20:01:13 Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI rev. 7 status would this include an updated error recovery section ? -Sandeep > Really soon (3-4 weeks at most perhaps even earlier). > > Julo > > Chuck Micalizzi on 01-06-2001 00:47:36 > > Please respond to Chuck Micalizzi > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: iSCSI rev. 7 status > > > > > Julian, > > Do you expect to be posting version 7 anytime soon? > > thanks > > chuck > From owner-ips@ece.cmu.edu Sat Jun 2 16:36:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13454 for ; Sat, 2 Jun 2001 16:36:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f52IcoY04232 for ips-outgoing; Sat, 2 Jun 2001 14:38:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f52Icng04228 for ; Sat, 2 Jun 2001 14:38:49 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA31268 for ; Sat, 2 Jun 2001 20:38:42 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.96) with SMTP id UAA41816 for ; Sat, 2 Jun 2001 20:38:42 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A5F.006655C9 ; Sat, 2 Jun 2001 20:37:46 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sat, 2 Jun 2001 20:47:22 +0300 Subject: Re: iscsi: out of order unsolicited data Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk One TCP connection delivers data in order. Julo "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" on 01-06-2001 15:13:29 Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iscsi: out of order unsolicited data Hello, Page 17 of iscsi rev6 draft says Unsolicited data MUST be sent on every connection in the same order in which commands were sent. A target receiveing data out of order SHOULD termintate the session My question is if the PDU was delivered in correct order from initiator but not received in correct order by target because it got missed somewhere in the path, shouldn't the target wait for retransmission instead of terminating the session. Regards, Sanjeev - att1.htm From owner-ips@ece.cmu.edu Sun Jun 3 22:25:52 2001 Received: from ece.cmu.edu ([128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13663 for ; Sun, 3 Jun 2001 22:25:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f540NiL29621 for ips-outgoing; Sun, 3 Jun 2001 20:23:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f540Nhg29617 for ; Sun, 3 Jun 2001 20:23:43 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA69826 for ; Sun, 3 Jun 2001 20:16:00 -0400 Received: from f3n41e (d03nm041h.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1/NCO v4.96.1.0) with ESMTP id f540Nfs156878 for ; Sun, 3 Jun 2001 18:23:41 -0600 Importance: Normal Subject: Remove To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Dick Booth" Date: Sat, 2 Jun 2001 14:31:57 -0700 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/03/2001 05:23:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Remove From owner-ips@ece.cmu.edu Mon Jun 4 04:54:23 2001 Received: from ece.cmu.edu ([128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01812 for ; Mon, 4 Jun 2001 04:54:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f546klm16047 for ips-outgoing; Mon, 4 Jun 2001 02:46:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f546kkg16043 for ; Mon, 4 Jun 2001 02:46:46 -0400 (EDT) Received: (cpmta 4608 invoked from network); 3 Jun 2001 23:46:39 -0700 Received: from unknown (HELO littlejoy) (64.130.130.105) by smtp.telocity.com (209.228.33.219) with SMTP; 3 Jun 2001 23:46:39 -0700 X-Sent: 4 Jun 2001 06:46:39 GMT From: "Douglas Otis" To: "David Robinson" Cc: "David Robinson" , "Bernard Aboba" , , Subject: RE: iSCSI and secure boot Date: Sun, 3 Jun 2001 23:44:16 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3B1B03E4.BCB76375@ebay.sun.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, > Doug I think you are thinking about the wrong problem. Assume that > there > is a perfectly coded iSCSI client that is burned into the PROM of every > initiator shipped. There is still a booting issue, to login to the > iSCSI target securely there must be a key on each initiator. You cannot > get that key from another entity on the network (LDAP) securely without > first > having some key to protect that connection. You can install keys at the > factory but as Bernard points out, most keys get invalidated so it is > necessary to have a management mechanism to update all the keys. The > same problem exists regardless of which protocol is in the PROM, any > of PXE, DHCP, LDAP, or iSCSI have the same secure bootstrapping > problem. > > > You already have initial image that can be trusted based on stored > > information. This information does not go away. Use this stored > > information as a shared secret merged with information within > > the boot image > > to then continue the next step of the process. > > This assumes that the initiator has a factory set key that will always > be considered valid and cannot be compromised (i.e. unreadable). Without > this there must be a mechanism to update and manage those keys securely. > While I am sure there are intelligent people working on this problem, > it really isn't something that the ips working groups should be solving. You should review information regarding the two step process for booting. http://www.intel.com/ial/wfm/tools/bis/ http://www.intel.com/ial/wfm/wfmspecs.htm You seem confused about the way keys are created. You also suggest to have TFTP replaced with iSCSI suggesting something as complex as iSCSI is easily coded in a primative boot environment. That makes little sense if the goal to to minimize the amount of support required and would not likely interest system or network adapter manufactures. > > No, the problem is not that it will not scale. This is not > > analogous to a > > login. If you wanted a secure agent that could remotely modify > > these keys, > > it could be done, but I do not think that to be a good thing. > > What problem > > should this solve? It will not scale if each machine must be > > individually > > handled every few weeks when a protocol changes or an update goes awry. > > No, it is not the issue of updating the boot image, but updating the > keys > that doesn't scale. Again, what problem are you attempting to solve? I know of no system that does not require some initial setup. The problems you are concerned with are being addressed. I would endorse only using stable protocols in this boot process and is the reason for using LDAP versus mucking with DHCP and placing management functions within the iSCSI transport. Doug From owner-ips@ece.cmu.edu Mon Jun 4 14:45:34 2001 Received: from ece.cmu.edu ([128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15554 for ; Mon, 4 Jun 2001 14:45:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f54GK4E25439 for ips-outgoing; Mon, 4 Jun 2001 12:20:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f54FWPg22423 for ; Mon, 4 Jun 2001 11:32:26 -0400 (EDT) Received: from phys-ha6nwkb.ebay.sun.com ([129.149.1.83]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00244; Mon, 4 Jun 2001 09:32:24 -0600 (MDT) Received: from ebay.sun.com (dsl197-15.Eng.Sun.COM [129.146.197.15]) by phys-ha6nwkb.ebay.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21433; Mon, 4 Jun 2001 08:32:24 -0700 (PDT) Message-ID: <3B1BA986.11FA0C7@ebay.sun.com> Date: Mon, 04 Jun 2001 08:30:14 -0700 From: David Robinson X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Douglas Otis CC: David Robinson , David Robinson , Bernard Aboba , julian_satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI and secure boot References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > You should review information regarding the two step process for booting. > http://www.intel.com/ial/wfm/tools/bis/ > http://www.intel.com/ial/wfm/wfmspecs.htm > > You seem confused about the way keys are created. You also suggest to have > TFTP replaced with iSCSI suggesting something as complex as iSCSI is easily > coded in a primative boot environment. That makes little sense if the goal > to to minimize the amount of support required and would not likely interest > system or network adapter manufactures. Again it appears that we are talking about two different things, so this will be my last comment on this thread. I am aware of the Intel boot initiatives. I was not suggesting that we require a full iSCSI in PROM, just using it as an example that the problem of secure keying exists regardless of the protocol used, from the trivial TFTP to the complex iSCSI. That said, someone will eventually put a full iSCSI initiator into PROM. > > No, it is not the issue of updating the boot image, but updating the > > keys > > that doesn't scale. > > Again, what problem are you attempting to solve? I know of no system that > does not require some initial setup. The problems you are concerned with > are being addressed. I would endorse only using stable protocols in this > boot process and is the reason for using LDAP versus mucking with DHCP and > placing management functions within the iSCSI transport. Again this whole discussion is about how to reliably securely boot iSCSI. This topic necessarily focuses on how to insure that the client can be securely identified, thus using some sort of key that is manageable. Finally I can't understand how the current proposal mucks with DHCP, it uses the standard mechanisms. As described it specifies a new option code which is a trivial thingto implement and it has also been proposed to use existing option codes. There is no invention here, and in fact it is simpiler than specifying an LDAP schema. -David From owner-ips@ece.cmu.edu Mon Jun 4 16:26:31 2001 Received: from ece.cmu.edu ([128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18650 for ; Mon, 4 Jun 2001 16:26:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f54IEmo03749 for ips-outgoing; Mon, 4 Jun 2001 14:14:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f54IEkg03745 for ; Mon, 4 Jun 2001 14:14:47 -0400 (EDT) Received: (cpmta 3616 invoked from network); 4 Jun 2001 11:14:40 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.219) with SMTP; 4 Jun 2001 11:14:40 -0700 X-Sent: 4 Jun 2001 18:14:40 GMT From: "Douglas Otis" To: "David Robinson" Cc: "David Robinson" , "Bernard Aboba" , , Subject: RE: iSCSI and secure boot Date: Mon, 4 Jun 2001 11:12:18 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3B1BA986.11FA0C7@ebay.sun.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, > Again this whole discussion is about how to reliably securely boot > iSCSI. This topic necessarily focuses on how to insure that the client > can be securely identified, thus using some sort of key that is > manageable. > > Finally I can't understand how the current proposal mucks with DHCP, it > uses the standard mechanisms. As described it specifies a new option code > which is a trivial thing to implement and it has also been proposed to > use existing option codes. There is no invention here, and in fact it is > simpiler than specifying an LDAP schema. You are suggesting that two versions of iSCSI be created. One that can exist within the lean environment within pre-boot and another within the OS of your choice. I am not convinced that the prior version of iSCSI would be a wise investment for many reasons. If you have some difficulty with the manner in which the Wire-For-Management proposals work, perhaps you could address those points specifically. At least it would come from a perspective that illustrates your concern as to why the Boot-Integrity-Service, Pre-Execution-Environment, and Wired-for-management solutions are not meeting the needs of enabling a secure boot. I for one would like to understand your concern. The invention comes from redefining the purpose of DHCP options as a means of extracting the needed management functions which are then used in conjunction with embedded queries within the iSCSI transport. As if iSCSI was not complex enough, placing this management function into the transport is where I am suggesting there is again over-reaching. This is not a required approach nor one that takes advantage of available services. In addition to that, a boot image would be far more stable using LDAP than to depend on the ability to modify DHCP to provide tailored responses for then interaction within iSCSI. You seem to suggest that reinventing these services is easier than understanding what already exists. This type of tailoring should be done using LDAP and not with DHCP or iSCSI or yet another new server service. Doug From owner-ips@ece.cmu.edu Mon Jun 4 19:10:34 2001 Received: from ece.cmu.edu ([128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21145 for ; Mon, 4 Jun 2001 19:10:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f54Knlc16258 for ips-outgoing; Mon, 4 Jun 2001 16:49:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f54Knkg16254 for ; Mon, 4 Jun 2001 16:49:46 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA18274 for ; Mon, 4 Jun 2001 16:49:40 -0400 (EDT) Message-ID: <3B1BF394.3C3A01CB@cisco.com> Date: Mon, 04 Jun 2001 15:46:12 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI Discovery and SendTargets Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We have had several discussions, both on and off the list, during and since the interim meeting on the SendTargets text command. These discussions have included the following topics: 1. Use of a default or well-known target for SendTargets and related functions only. 2. Iteration of the SendTargets command for responses that will exceed the capacity of a single text response. 3. The addition of other information to the SendTargets response, such as aggregation tags, certificate subject names, or even certificates themselves, and perhaps boot-related information. 4. The splitting of SendTargets into two commands: ReportTargets - used on a well-known target connection to get the list of target names the initiator should look for, and at least one address for each. ReportPortalGroups - similar to SendTargets, but done on an operational iSCSI connection, and returning only the addresses for the particular target to which the connection belongs. The question has been raised as to whether the addition of these features, along with the separation of SendTargets on its own connection type, really turns SendTargets into its own protocol. So if SendTargets is its own protocol, the question morphs into "why not use a standard protocol already defined for this purpose?" If we consider that the purpose of SendTargets is to discover a set of targets and their addresses, protocols such as SLP and SSDP (used by universal plug & play), and those provided by Jini, Salutation, and others, already provide this. As we have gone through the selection exercise before of deciding which of these to use for multicast discovery, we assumed that the correct protocol is SLP. Providing SLP support for iSCSI targets and initiators allows initiator to discover targets and their addresses without a lot of configuration. Specifically, an initiator does not need to be configured with any of the address of its targets; it can discover them either through multicast requests, or by contacting an optional directory agent. Back to the naming & discovery requirements, and ignoring the specific discovery protocols used, an initiator may be configured with target information in a number of ways: - The iSCSI target name and each of its addresses. In this case, absolutely no discovery is needed; the user did it already. - The iSCSI target name and one of its addresses. In this case, the initiator can log in to the target, but needs a mechanism to find out if there are more addresses on which the target may be found. SendTargets fills this need. - The address at which an iSCSI target may be found. In this case, no target name is included; the initiator is expected to contact the iSCSI entity at this address and find out which targets it is supposed to see. This is what SendTargets is intended to do. - The iSCSI target name with no address. In this case, there are no hints given as to where the target is; the inititator must have a further discovery mechanism configured to resolve this name. SLP, iSNS, and SendTargets as a directory mechanism are all set up to fill this need, with varying amounts of configuration required. - No iSCSI target names or addresses. In this case there are no hints even at which targets the initiator should see. Again, a further discovery mechanism is required. Of course, most of the above methods are compatible with each other; one could configure an initiator to look for some iSCSI target names, and also go ask a few particular addresses, and also do multicast to go find any other targets that might be necessary. This means that we really aren't choosing amongst the above options; we must eventually enable all of them, and let the users decide which one makes life easiest in their environment. When the configuration method requires a discovery mechanism, there are a few proposed ways of implementing discovery: 1. SLP can provide discovery with varying levels of configuration required: - If nothing is configured, SLP will use un-authenticated multicast requests to find its targets. - If the user configures SLP authentication, it can do authenticated multicast requests in the same manner. - If the user configures an SLP directory agent address (or assigns it via DHCP), and does this on the initiator and target, discovery can be done without using multicast. The only thing missing is the ability to configure the initiator with the address of the target, and have it do the unicast request over TCP without a directory agent. This is the gap that SendTargets currently fills. 2. A SendTargets tree has been verbally proposed that would include some sort of software implementation that knew about targets and addresses for a collection of devices. Such an implementation may be part of a vendor's storage management software. The initiator would be configured with the IP address of a well-known target on the management station, and use SendTargets to get the list of target names and addresses of the actual devices (implemented elsewhere) to which it can connect. By responding with other well- known targets to which to make further requests, a hierarchy of SendTargets servers can be built. This has the advantage of using the same login and authentication schemes as iSCSI, since it is built on the iSCSI text commands. It has the disadvantage that zero-configuration is not possible, but a very simplified SLP template could be used to remedy this. 3. iSNS has been proposed to fulfill the same requirements. iSNS can fulfill each of the configuration requirements through an iSNS server. iSNS does not define a method for an initiator to discover a target directly without an iSNS server, or to contact a target directly to gain a list of its addresses. Zero-configuration of initiators in an iSNS enviroment is done by listening for iSNS heartbeat messages advertising the iSNS servers. iSNS servers can also be discovered using SLP. Like an SLP DA, an iSNS server's address (and optional authentication information) can be configured on each host and device to avoid multicast; it can also be assigned to hosts using DHCP. Since SLP was the only protocol with only one of the configuration abilities missing (the ability to contact a target directly using a configured unicast address), I decided to take a look to see if it could be modified to add this as well. I spent some time hacking at the OpenSLP, which is an open-source, BSD-license SLP implementation. The hack I did was to allow the SLP user agent (UA; which would be integrated with an initiator) to specify the IP address of a service agent (SA; which would be integrated with a target), instead of finding the SA via multicast. Basically, the UA opened a TCP connection to the SA, sent its ServiceRequest message asking for iSCSI targets, and received a ServiceResponse containing the addresses advertised for the iSCSI targets. The information contained in the response was identical to the information that would have been provided by SendTargets. Modifying SLP in such a way caused no changes to be made to the protocol's message formats, to the SA or to the directory agent (DA, if one is present). The only change was a behavioral change in the UA. A brief conversation with one of the SLP developers found that other people have been thinking of adding the same functionality for other reasons, so I don't think we would be adding something that would not be supported by the SLP folks. Anyway, that's subject to verification. After verifying that SLP can indeed be modified to fulfill each of the initiator's configuration requirements from a technical perspective, we now have to look at a few other problems, such as differences in authentication schemes, and the expediency of getting products released and interoperability- tested. Here are the differences between using a Unicast SLP for the SendTargets function and using SendTargets as-is: 1. Expediency - SendTargets is very easy to implement, many of us have already implemented it, and I believe that it is intented to be tested at the UNH plugfest in July. Given this, SendTargets is probably the best way to go. 2. Philosophy - The internetworking philosophy is to build a bunch of smaller "functional" protocols. Each of these protocols is designed to do one function, do it well, and do it for everybody. For example, if I was to build an NFS server, I would use: NTP - to coordinate time DNS - to resolve host names into addresses DHCP - to assign IP addresses and other information RADIUS - to request authentication of a username/password hash. SNMP - to monitor the server CIM - to configure the server and so on. These protocols are modified over time, and new versions introduced, as services are added that stretch their original boundaries. However, their basic function remains the same. SLP fits in with these best; it's designed to allow service discovery for a whole bunch of unrelated services, and that's all it attempts to do. SSDP and other protocols are also in this boat. The opposite philosophy is to build a single protocol that contains just what is needed for a particular solution out of each of the above categories of protocols. This can be more expedient, but is probably frowned upon by the IESG folks. Given this, SLP is probably the better philosophical way to go. 3. On the other hand, one could argue that SendTarget is really a lot like "Report LUNs" for SCSI, or like "ls" for ftp, and is really just providing a directory listing, not full discovery. 4. Amount of code. SLP will require somewhat more code to implement than SendTargets, but at least there are code bases available. So SendTargets will have the initial smaller footprint, but as implementations add both SendTargets and SLP (for zero-configuration), the combined code base will be larger than if everyone just used SLP in the first place. 5. Authentication - The really hard part of all of this is that SendTargets is the only method of discovery that can actually share the exact same login & authentication method with the iSCSI protocol itself. This makes it really easy for an implementation to say that its authentication during discovery is "at-least-as-good" as the authentication between the eventual initiator and target. SLP can be authenticated as well, but since it uses a different authentication mechanism, we will have to take more time to figure out how to guarantee that it's "at-least-as-good" in all cases. Anyway, those are some thoughts; I am sure there are more. Unfortunately for me, I have found that I am able to argue most of these points from either side. In the end, we have three options: 1. Keep SendTargets as-is in the iSCSI protocol, finish our discussions on the original four topics, and add whatever is needed. 2. Reserve the well-known target "iscsi" within the iSCSI specification, with the note that interaction with this target is for discovery purposes documented elsewhere, and moving all well-know target functions (currently SendTargets), to another document. 3. Drop SendTargets in favor of a "functional" protocol such as SLP. In either of the three options, the naming & discovery team' rough consensus was that we keep at least the ReportPortalGroups functionality within iSCSI. From an expediency vs. philosophical correctness of having a single discovery protocol, there are combinations: - Implement SendTargets now, let it be used as a hierarchy, and provide an optional, simplified SLP template to discover only the well-known targets. The real information is now provided only within SendTargets or its kin. - Implement SendTargets now, but keep it as simple as possible, and encourage that discovery implementations migrate to SLP later on. This would stop the growth of SendTargets into its own protocol, but get us something to work with for the very near term. - Probably more, but it's getting late. Perhaps one of the former two "compromise" bullets, perhaps combined with option (2) to move SendTargets to another document will be the right balance between expediency and overall philophical consistency. One important point to make is that regardless of the path we choose, we ought to at least reserve a well-known target name such as "iscsi", in case we need to add other things in the future that do not address any specific SCSI target. The SCSI folks have had the same problem within a target; there is no way to address a command to a whole target, so target-specific commands have had to use LUN 0. Perhaps a way to address the iSCSI target "all" or the iSCSI target "nothing" would be the way to go. OK, the can is open. Any comments? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jun 4 23:51:58 2001 Received: from ece.cmu.edu ([128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26414 for ; Mon, 4 Jun 2001 23:51:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5526c906554 for ips-outgoing; Mon, 4 Jun 2001 22:06:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5526bg06550 for ; Mon, 4 Jun 2001 22:06:37 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 19:05:46 -0700 Message-ID: From: Joshua Tseng To: "'Mark Bakke'" , IPS Subject: RE: iSCSI Discovery and SendTargets Date: Mon, 4 Jun 2001 19:04:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, I just wanted to add some additional information about iSNS that might help make this analysis easier. > iSNS does not define a method for an initiator to discover > a target directly without an iSNS server, or to contact a > target directly to gain a list of its addresses. There is no reason why an iSNS server can't be deployed in a target device just to support that device's targets, and for the iSNS protocol to fulfill the capabilities that are described in your memo regarding simple iSCSI discovery. I do not see a fundamental difference between deploying an SLP SA on each target, and deploying an iSNS server on each target. iSNS can be scaled down as well to fulfill simple discovery, if that's all that is required. As I look down the list of SLP capabilities, there is nothing I see that iSNS does not also provide. A comparison of iSNS server code with SLP SA code shows that they are not significantly different in size (both are roughly 10,000 loc). But with iSNS, you also have management capabilities such as Zoning (DD's), which allow an iSCSI device to display a different view of its targets to each initiator. This might be especially important in a mixed NT/Unix environment. On the other hand, if the goal is to scale down to a simple, discovery mechanism, all the management capabilities (zoning, ESI polling, etc...) can be removed from iSNS, resulting in an even lighterweight implementation. Josh > > We have had several discussions, both on and off the list, > during and since the interim meeting on the SendTargets text > command. These discussions have included the following > topics: > > 1. Use of a default or well-known target for SendTargets and > related functions only. > > 2. Iteration of the SendTargets command for responses that will > exceed the capacity of a single text response. > > 3. The addition of other information to the SendTargets response, > such as aggregation tags, certificate subject names, or even > certificates themselves, and perhaps boot-related information. > > 4. The splitting of SendTargets into two commands: > > ReportTargets - used on a well-known target connection to > get the list of target names the initiator should look for, > and at least one address for each. > > ReportPortalGroups - similar to SendTargets, but done on an > operational iSCSI connection, and returning only the addresses > for the particular target to which the connection belongs. > > The question has been raised as to whether the addition of these > features, along with the separation of SendTargets on its own > connection type, really turns SendTargets into its own protocol. > So if SendTargets is its own protocol, the question morphs into > "why not use a standard protocol already defined for this purpose?" > > If we consider that the purpose of SendTargets is to discover > a set of targets and their addresses, protocols such as SLP > and SSDP (used by universal plug & play), and those provided by > Jini, Salutation, and others, already provide this. As we have > gone through the selection exercise before of deciding which of > these to use for multicast discovery, we assumed that the correct > protocol is SLP. > > Providing SLP support for iSCSI targets and initiators allows > initiator to discover targets and their addresses without a lot > of configuration. Specifically, an initiator does not need to > be configured with any of the address of its targets; it can > discover them either through multicast requests, or by contacting > an optional directory agent. > > Back to the naming & discovery requirements, and ignoring the > specific discovery protocols used, an initiator may > be configured with target information in a number of ways: > > - The iSCSI target name and each of its addresses. In this case, > absolutely no discovery is needed; the user did it already. > > - The iSCSI target name and one of its addresses. In this case, > the initiator can log in to the target, but needs a mechanism > to find out if there are more addresses on which the target may > be found. SendTargets fills this need. > > - The address at which an iSCSI target may be found. In this case, > no target name is included; the initiator is expected to contact > the iSCSI entity at this address and find out which targets it is > supposed to see. This is what SendTargets is intended to do. > > - The iSCSI target name with no address. In this case, there are > no hints given as to where the target is; the inititator must have > a further discovery mechanism configured to resolve this name. > SLP, iSNS, and SendTargets as a directory mechanism are all set > up to fill this need, with varying amounts of configuration > required. > > - No iSCSI target names or addresses. In this case there are no > hints even at which targets the initiator should see. Again, > a further discovery mechanism is required. > > Of course, most of the above methods are compatible with each other; > one could configure an initiator to look for some iSCSI target names, > and also go ask a few particular addresses, and also do multicast > to go find any other targets that might be necessary. This means > that we really aren't choosing amongst the above options; we must > eventually enable all of them, and let the users decide which one > makes life easiest in their environment. > > When the configuration method requires a discovery mechanism, there > are a few proposed ways of implementing discovery: > > 1. SLP can provide discovery with varying levels of configuration > required: > > - If nothing is configured, SLP will use un-authenticated > multicast requests to find its targets. > > - If the user configures SLP authentication, it can do > authenticated multicast requests in the same manner. > > - If the user configures an SLP directory agent address (or > assigns it via DHCP), and does this on the initiator and > target, discovery can be done without using multicast. > > The only thing missing is the ability to configure the > initiator with the address of the target, and have it > do the unicast request over TCP without a directory agent. > This is the gap that SendTargets currently fills. > > 2. A SendTargets tree has been verbally proposed that would > include some sort of software implementation that knew about > targets and addresses for a collection of devices. Such an > implementation may be part of a vendor's storage management > software. The initiator would be configured with the IP > address of a well-known target on the management station, > and use SendTargets to get the list of target names and > addresses of the actual devices (implemented elsewhere) > to which it can connect. By responding with other well- > known targets to which to make further requests, a > hierarchy of SendTargets servers can be built. > > This has the advantage of using the same login and authentication > schemes as iSCSI, since it is built on the iSCSI text commands. > > It has the disadvantage that zero-configuration is not > possible, but a very simplified SLP template could be used > to remedy this. > > 3. iSNS has been proposed to fulfill the same requirements. > > iSNS can fulfill each of the configuration requirements > through an iSNS server. > > iSNS does not define a method for an initiator to discover > a target directly without an iSNS server, or to contact a > target directly to gain a list of its addresses. > > Zero-configuration of initiators in an iSNS enviroment is > done by listening for iSNS heartbeat messages advertising > the iSNS servers. iSNS servers can also be discovered using > SLP. > > Like an SLP DA, an iSNS server's address (and optional > authentication information) can be configured on each host > and device to avoid multicast; it can also be assigned to > hosts using DHCP. > > > Since SLP was the only protocol with only one of the configuration > abilities missing (the ability to contact a target directly using > a configured unicast address), I decided to take a look to see if > it could be modified to add this as well. > > I spent some time hacking at the OpenSLP, which is an open-source, > BSD-license SLP implementation. The hack I did was to allow the > SLP user agent (UA; which would be integrated with an initiator) > to specify the IP address of a service agent (SA; which would be > integrated with a target), instead of finding the SA via multicast. > Basically, the UA opened a TCP connection to the SA, sent its > ServiceRequest message asking for iSCSI targets, and received a > ServiceResponse containing the addresses advertised for the iSCSI > targets. The information contained in the response was identical > to the information that would have been provided by SendTargets. > > Modifying SLP in such a way caused no changes to be made to the > protocol's message formats, to the SA or to the directory agent > (DA, if one is present). The only change was a behavioral change > in the UA. A brief conversation with one of the SLP developers > found that other people have been thinking of adding the same > functionality for other reasons, so I don't think we would be adding > something that would not be supported by the SLP folks. Anyway, > that's subject to verification. > > After verifying that SLP can indeed be modified to fulfill > each of the initiator's configuration requirements from a > technical perspective, we now have to look at a few other > problems, such as differences in authentication schemes, and > the expediency of getting products released and interoperability- > tested. > > Here are the differences between using a Unicast SLP for the > SendTargets function and using SendTargets as-is: > > 1. Expediency - SendTargets is very easy to implement, many of us > have already implemented it, and I believe that it is intented > to be tested at the UNH plugfest in July. > > Given this, SendTargets is probably the best way to go. > > 2. Philosophy - The internetworking philosophy is to build a > bunch of smaller "functional" protocols. Each of these > protocols is designed to do one function, do it well, and do > it for everybody. For example, if I was to build an NFS > server, I would use: > > NTP - to coordinate time > DNS - to resolve host names into addresses > DHCP - to assign IP addresses and other information > RADIUS - to request authentication of a username/password > hash. > SNMP - to monitor the server > CIM - to configure the server > and so on. > > These protocols are modified over time, and new versions > introduced, as services are added that stretch their original > boundaries. However, their basic function remains the same. > > SLP fits in with these best; it's designed to allow service > discovery for a whole bunch of unrelated services, and that's > all it attempts to do. SSDP and other protocols are also > in this boat. > > The opposite philosophy is to build a single protocol that contains > just what is needed for a particular solution out of each of > the above categories of protocols. This can be more expedient, > but is probably frowned upon by the IESG folks. > > Given this, SLP is probably the better philosophical way > to go. > > 3. On the other hand, one could argue that SendTarget is really > a lot like "Report LUNs" for SCSI, or like "ls" for ftp, and > is really just providing a directory listing, not full discovery. > > 4. Amount of code. SLP will require somewhat more code to implement > than SendTargets, but at least there are code bases available. > So SendTargets will have the initial smaller footprint, but as > implementations add both SendTargets and SLP (for > zero-configuration), > the combined code base will be larger than if everyone just > used SLP in the first place. > > 5. Authentication - The really hard part of all of this is that > SendTargets is the only method of discovery that can actually > share the exact same login & authentication method with the > iSCSI protocol itself. This makes it really easy for an > implementation > to say that its authentication during discovery is > "at-least-as-good" > as the authentication between the eventual initiator and target. > SLP can be authenticated as well, but since it uses a different > authentication mechanism, we will have to take more time to figure > out how to guarantee that it's "at-least-as-good" in all cases. > > Anyway, those are some thoughts; I am sure there are more. > > Unfortunately for me, I have found that I am able to argue most of > these points from either side. > > In the end, we have three options: > > 1. Keep SendTargets as-is in the iSCSI protocol, finish our > discussions > on the original four topics, and add whatever is needed. > > 2. Reserve the well-known target "iscsi" within the iSCSI > specification, > with the note that interaction with this target is for discovery > purposes documented elsewhere, and moving all well-know target > functions (currently SendTargets), to another document. > > 3. Drop SendTargets in favor of a "functional" protocol such as SLP. > > In either of the three options, the naming & discovery team' rough > consensus was that we keep at least the ReportPortalGroups > functionality within iSCSI. > > From an expediency vs. philosophical correctness of having a single > discovery protocol, there are combinations: > > - Implement SendTargets now, let it be used as a hierarchy, and > provide an optional, simplified SLP template to discover only > the well-known targets. The real information is now provided > only within SendTargets or its kin. > > - Implement SendTargets now, but keep it as simple as possible, > and encourage that discovery implementations migrate to SLP > later on. This would stop the growth of SendTargets into its > own protocol, but get us something to work with for the very > near term. > > - Probably more, but it's getting late. Perhaps one of the former > two "compromise" bullets, perhaps combined with option (2) to > move SendTargets to another document will be the right balance > between expediency and overall philophical consistency. > > One important point to make is that regardless of the path we > choose, we ought to at least reserve a well-known target name > such as "iscsi", in case we need to add other things in the > future that do not address any specific SCSI target. The SCSI > folks have had the same problem within a target; there is no > way to address a command to a whole target, so target-specific > commands have had to use LUN 0. Perhaps a way to address the > iSCSI target "all" or the iSCSI target "nothing" would be the > way to go. > > OK, the can is open. Any comments? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Mon Jun 4 23:55:32 2001 Received: from ece.cmu.edu ([128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26436 for ; Mon, 4 Jun 2001 23:55:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f552AKO06781 for ips-outgoing; Mon, 4 Jun 2001 22:10:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f552AHg06757 for ; Mon, 4 Jun 2001 22:10:17 -0400 (EDT) Received: from cs.uchicago.edu ([24.91.83.49]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f552AGx28249 for ; Mon, 4 Jun 2001 22:10:16 -0400 (EDT) Message-Id: <200106050210.f552AGx28249@chmls05.mediaone.net> To: ips@ece.cmu.edu Subject: Re: iSCSI Discovery and SendTargets In-Reply-To: Message from Mark Bakke of "Mon, 04 Jun 2001 15:46:12 CDT." <3B1BF394.3C3A01CB@cisco.com> References: <3B1BF394.3C3A01CB@cisco.com> Date: Mon, 04 Jun 2001 22:08:05 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, > Any comments? I'm exhausted after reading your message. > The only thing missing is the ability to configure the > initiator with the address of the target, and have it > do the unicast request over TCP without a directory agent. > This is the gap that SendTargets currently fills. Once upon a time, I had imagined that iSCSI targets would implement a `minimal' SLP directory agent for the purposes of doing this unicast discovery. However, a cursory scan of the SLP RFC suggests that this might be running roughshod over the protocol, and more importantly, a minimal SLP directory agent looks pretty bulky. Sigh, rats. Oh well. Nonetheless, I still think that tweaking SLP to do the job would be an OK idea, and perhaps the right architectural approach, if the SLP guys are sold on standardizing it. Steph From owner-ips@ece.cmu.edu Tue Jun 5 08:10:53 2001 Received: from ece.cmu.edu ([128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16703 for ; Tue, 5 Jun 2001 08:10:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f55A2Nq15154 for ips-outgoing; Tue, 5 Jun 2001 06:02:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nest.stpt.soft.net ([203.200.144.37]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f55A2Kg15132 for ; Tue, 5 Jun 2001 06:02:20 -0400 (EDT) Received: from pdc2.nest.stpt.soft.net (pdc2 [192.168.192.5]) by nest.stpt.soft.net (8.6.8.1/SCA-6.6) with ESMTP id JAA28268 for ; Tue, 5 Jun 2001 09:12:52 GMT Organization: NeST India Received: by pdc2.nestec.net with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 15:29:53 +0530 Message-ID: From: FAIZAL C K To: ips@ece.cmu.edu Subject: iSCSI? Date: Tue, 5 Jun 2001 15:29:50 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Gurus... I am very new to iSCSI. Please give me answer for some questions. 1) What is the latest version of spec available in the net? (could you point out that please?) 2) Can I use this now? Means..I want to send some scsi commands over IP for my new project. 3) need any iSCSI complaint hardware or driver? 4) Any APIs? TIA, Faizal From owner-ips@ece.cmu.edu Tue Jun 5 14:46:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28064 for ; Tue, 5 Jun 2001 14:46:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f55GwX214502 for ips-outgoing; Tue, 5 Jun 2001 12:58:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f55GwUg14498 for ; Tue, 5 Jun 2001 12:58:30 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 2A6343B for ; Tue, 5 Jun 2001 18:58:26 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id RAA04207 for ; Tue, 5 Jun 2001 17:58:25 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Tue, 05 Jun 2001 17:58:25 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 17:58:25 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A738@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: Unsolicited Data. Date: Tue, 5 Jun 2001 17:58:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm not sure if this has been discussed before but it is causing some confusion. The statement below implies that if immediate data has been negotiated then the initiator MAY use it. "If ImmediateData is set to no and InitialR2T is set to no then the initiator MUST NOT send unsolicited immediate data but MAY send one unsolicited burst of Data-OUT PDUs." Therefore the target must wait for the initial burst of unsolicited data before issuing the first R2T (if there is subsequent data). If the initiator decides not to send it then the target must timeout and issue the R2T for the initial data. Can the spec be changed to state that if unsolicited data has been negotiated, then the initiator MUST use it. Thanks Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Tue Jun 5 14:48:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28096 for ; Tue, 5 Jun 2001 14:48:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f55Gjb913488 for ips-outgoing; Tue, 5 Jun 2001 12:45:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f55GjZg13484 for ; Tue, 5 Jun 2001 12:45:35 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 4914F121 for ; Tue, 5 Jun 2001 18:45:34 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id RAA03352 for ; Tue, 5 Jun 2001 17:45:33 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Tue, 05 Jun 2001 17:45:33 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 17:45:33 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A737@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu Subject: Section 4.1 Login Phase Start Date: Tue, 5 Jun 2001 17:45:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm confused by the following statement from section 4.1 (third paragraph. "... However, it is OPTIONAL for all the connections after the first. It is ignored by the target for new connections within an existing session." If the iSCSI target Name is ignored by the target on all connections other than the first then why is it optional for the initiator to include it. Either it is optional and the target should not ignore it (e.g. check the name against the existing session), or it should not be sent at all. Thanks Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Tue Jun 5 14:57:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28209 for ; Tue, 5 Jun 2001 14:57:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f55HWKB17260 for ips-outgoing; Tue, 5 Jun 2001 13:32:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f55HWHg17244 for ; Tue, 5 Jun 2001 13:32:17 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-139.cisco.com [161.44.68.139]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA18374 for ; Tue, 5 Jun 2001 13:32:11 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: Unsolicited Data. Date: Tue, 5 Jun 2001 12:31:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC101E7A738@dickens.bri.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit If the initiator decides not to send immediate or unsolicited data when it has negotiated to do so, then the initiator must set the F-bit in the command PDU. This prompts the target to send R2T. I still agree that the spec should indicate that the initiator MUST use the resources it has negotiated. If it has negotiated the option to send immediate data or unsolicited data then it should do that to the limits allowed. If it has negotiated a PDU length, it must not send data PDUs less than the negotiated limit except for last one. While most implementation may do that for performance reasons, I would prefer defining this in the spec. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > Sent: Tuesday, June 05, 2001 11:58 AM > To: 'ips@ece.cmu.edu' > Subject: Unsolicited Data. > > > I'm not sure if this has been discussed before but it is causing some > confusion. The statement below implies that if immediate data has been > negotiated then the initiator MAY use it. > > "If ImmediateData is set to no and InitialR2T is set to no then the > initiator MUST NOT send unsolicited immediate data but MAY send one > unsolicited burst of Data-OUT PDUs." > > Therefore the target must wait for the initial burst of unsolicited data > before issuing the first R2T (if there is subsequent data). If the > initiator decides not to send it then the target must timeout and > issue the > R2T for the initial data. Can the spec be changed to state that if > unsolicited data has been negotiated, then the initiator MUST use it. > > Thanks > > Matthew Burbridge > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > From owner-ips@ece.cmu.edu Tue Jun 5 17:04:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29964 for ; Tue, 5 Jun 2001 17:04:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f55IvkC24365 for ips-outgoing; Tue, 5 Jun 2001 14:57:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f55Ivhg24358 for ; Tue, 5 Jun 2001 14:57:44 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel2.hp.com (Postfix) with ESMTP id F047D1A73; Tue, 5 Jun 2001 11:57:42 -0700 (PDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 68CD21F50E; Tue, 5 Jun 2001 11:56:06 -0700 (PDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 14:57:40 -0400 Message-ID: <499DC368E25AD411B3F100902740AD6507778C9F@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Mark Bakke'" , IPS Subject: RE: iSCSI Discovery and SendTargets Date: Tue, 5 Jun 2001 14:57:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark and NDT team, Nice write-up of your discussions. In summary I would like to strongly support the position of option 1 in your memo, which is keeping SendTargets as-is with the few minor modifications to support aggregation tags, but not much else. We do need to contain the scope of SendTargets, but removing it from the spec would be a tremendous loss of a very simply yet powerful feature. My supporting comments are as follows: 1. Keeping SendTargets basically as-is, but with the addition of aggregation tags is a very small increment over what must already be implemented for general iSCSI login, authentication and text processing. It is basically just another text command that has very wide spread utility. 2. The fact that a discovery session, where SendTargets can be performed, uses the exact same authentication and login mechanisms is a fundamental benefit of the scheme. Alternatives will require their own (albeit similar) implementations for authentication. Deploying, configuring and maintaining AAA infrastructure has always been a stumbling block for customers and complicating this with additional protocols and clients will not help matters. 3. The complication of an iterator can be avoided if we restrict the usage of SendTargets to a session on a well-known target or clearly document the potential issues of blocking a connection in an implementation. However, I would support the definition of an iterator if there is consensus. This is not a show-stopper. 4. Splitting SendTargets into multiple commands (ReportTargets and ReportPortalGroups) seems unnecessary and not relevant. I have not heard the entire discussion surrounding ReportPortalGroups, but it would seem that this information would be better reported via the MIB or at least should be made available via the MIB. Even if there is a need for such a command then it appears to be an entirely separate issue. 5. Enhancing SendTarget responses to include additional information regarding certificates or boot related information appears to be in the category of 'creeping elegance' and does not to need to be considered at this time. Facilities will be in place to establish the session needed to perform SendTargets anyway, and returning additional information that allows one to avoid using these facilities is purely an optimization. 6. An example of SendTarget's power and simplicity (as-is) is the ability to use it to create a SendTargets tree as you've described. There is really nothing that "needs" to be changed from the current scheme to support this behavior. This is a perfect example of how the very same mechanism can be used to 'scale' in environments from very small plug-and-play workgroups to a large centrally administered, highly secured, enterprises. So, from an expediency and philosophical perspective I believe we should implement SendTargets now and contain the number of proposed changes to keep it as simply as possible. We should NOT move this to another document, since it is really just another text command, but a very powerful one at that. Paul +--------------------------+----------------------------+ + Paul Congdon + Email: paul_congdon@hp.com + + Hewlett Packard Company + Mail Stop: 5662 + + HP ProCurve Networking + Phone: (916) 785-5753 + + 8000 Foothills Blvd + Fax: (916) 785-5949 + + Roseville, CA 95747 + Mobile: (916) 765-4056 + +--------------------------+----------------------------+ From owner-ips@ece.cmu.edu Tue Jun 5 17:05:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29978 for ; Tue, 5 Jun 2001 17:05:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f55JDDO25634 for ips-outgoing; Tue, 5 Jun 2001 15:13:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f55JDAg25625 for ; Tue, 5 Jun 2001 15:13:11 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA45970; Tue, 5 Jun 2001 15:14:06 -0400 Received: from f3n42e (d03nm042h.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1/NCO v4.96.1.0) with ESMTP id f55JBqY113178; Tue, 5 Jun 2001 13:11:52 -0600 Importance: Normal Subject: RE: iSCSI Discovery and SendTargets To: "CONGDON,PAUL (HP-Roseville,ex1)" Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 5 Jun 2001 12:11:50 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/05/2001 12:11:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, Just a note of clarification. The ReportPortalGroups is intended to get the aggregation tags information for the specific target one is logged into. It's nothing more than that. You can think of SendTargets as the equivalent of "Send all Target Names with ReportPortalGroups for each". Or you can think of ReportPortalGroups as "SendTargets filtered by a specific iSCSI target name". It allows an iSCSI initiator to have only a name and ONE address for an iSCSI target, do login and THEN figure out about the aggregation tags (for multiple connection coordination), without having to do a SendTargets and possibly get back a lot of other target information that it (the initiator) doesn't care about. Jim Hafner "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on 06-05-2001 11:57:32 AM Sent by: owner-ips@ece.cmu.edu To: "'Mark Bakke'" , IPS cc: Subject: RE: iSCSI Discovery and SendTargets Mark and NDT team, Nice write-up of your discussions. In summary I would like to strongly support the position of option 1 in your memo, which is keeping SendTargets as-is with the few minor modifications to support aggregation tags, but not much else. We do need to contain the scope of SendTargets, but removing it from the spec would be a tremendous loss of a very simply yet powerful feature. My supporting comments are as follows: 1. Keeping SendTargets basically as-is, but with the addition of aggregation tags is a very small increment over what must already be implemented for general iSCSI login, authentication and text processing. It is basically just another text command that has very wide spread utility. 2. The fact that a discovery session, where SendTargets can be performed, uses the exact same authentication and login mechanisms is a fundamental benefit of the scheme. Alternatives will require their own (albeit similar) implementations for authentication. Deploying, configuring and maintaining AAA infrastructure has always been a stumbling block for customers and complicating this with additional protocols and clients will not help matters. 3. The complication of an iterator can be avoided if we restrict the usage of SendTargets to a session on a well-known target or clearly document the potential issues of blocking a connection in an implementation. However, I would support the definition of an iterator if there is consensus. This is not a show-stopper. 4. Splitting SendTargets into multiple commands (ReportTargets and ReportPortalGroups) seems unnecessary and not relevant. I have not heard the entire discussion surrounding ReportPortalGroups, but it would seem that this information would be better reported via the MIB or at least should be made available via the MIB. Even if there is a need for such a command then it appears to be an entirely separate issue. 5. Enhancing SendTarget responses to include additional information regarding certificates or boot related information appears to be in the category of 'creeping elegance' and does not to need to be considered at this time. Facilities will be in place to establish the session needed to perform SendTargets anyway, and returning additional information that allows one to avoid using these facilities is purely an optimization. 6. An example of SendTarget's power and simplicity (as-is) is the ability to use it to create a SendTargets tree as you've described. There is really nothing that "needs" to be changed from the current scheme to support this behavior. This is a perfect example of how the very same mechanism can be used to 'scale' in environments from very small plug-and-play workgroups to a large centrally administered, highly secured, enterprises. So, from an expediency and philosophical perspective I believe we should implement SendTargets now and contain the number of proposed changes to keep it as simply as possible. We should NOT move this to another document, since it is really just another text command, but a very powerful one at that. Paul +--------------------------+----------------------------+ + Paul Congdon + Email: paul_congdon@hp.com + + Hewlett Packard Company + Mail Stop: 5662 + + HP ProCurve Networking + Phone: (916) 785-5753 + + 8000 Foothills Blvd + Fax: (916) 785-5949 + + Roseville, CA 95747 + Mobile: (916) 765-4056 + +--------------------------+----------------------------+ From owner-ips@ece.cmu.edu Tue Jun 5 17:56:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00491 for ; Tue, 5 Jun 2001 17:56:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f55Jo1b28437 for ips-outgoing; Tue, 5 Jun 2001 15:50:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f55Jo0g28432 for ; Tue, 5 Jun 2001 15:50:00 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel2.hp.com (Postfix) with ESMTP id 2BDD713D7; Tue, 5 Jun 2001 12:49:59 -0700 (PDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 96C701F50F; Tue, 5 Jun 2001 12:48:21 -0700 (PDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 15:49:56 -0400 Message-ID: <499DC368E25AD411B3F100902740AD6507778CA1@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Jim Hafner'" , "CONGDON,PAUL (HP-Roseville,ex1)" Cc: ips@ece.cmu.edu Subject: RE: iSCSI Discovery and SendTargets Date: Tue, 5 Jun 2001 15:49:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, Thanks for the clarification. This seems like a reasonable optimization, but not something that one couldn't live without in practice. If not, it doesn't appear to be much of an extension to the existing mechanism anyway. Perhaps if a 'named' target is used in the command it only returns info about that target... Paul > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Tuesday, June 05, 2001 12:12 PM > To: CONGDON,PAUL (HP-Roseville,ex1) > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI Discovery and SendTargets > > > > Paul, > > Just a note of clarification. The ReportPortalGroups is > intended to get the > aggregation tags information for the specific target one is > logged into. > It's nothing more than that. You can think of SendTargets as the > equivalent of "Send all Target Names with ReportPortalGroups > for each". > Or you can think of ReportPortalGroups as "SendTargets filtered by a > specific iSCSI target name". > > It allows an iSCSI initiator to have only a name and ONE > address for an > iSCSI target, do login and THEN figure out about the > aggregation tags (for > multiple connection coordination), without having to do a > SendTargets and > possibly get back a lot of other target information that it > (the initiator) > doesn't care about. > > Jim Hafner > > > "CONGDON,PAUL (HP-Roseville,ex1)" @ece.cmu.edu on > 06-05-2001 11:57:32 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: "'Mark Bakke'" , IPS > cc: > Subject: RE: iSCSI Discovery and SendTargets > > > > > Mark and NDT team, > > Nice write-up of your discussions. In summary I would like > to strongly > support the position of option 1 in your memo, which is > keeping SendTargets > as-is with the few minor modifications to support aggregation > tags, but not > much else. We do need to contain the scope of SendTargets, > but removing it > from the spec would be a tremendous loss of a very simply yet powerful > feature. My supporting comments are as follows: > > 1. Keeping SendTargets basically as-is, but with the addition of > aggregation > tags is a very small increment over what must already be > implemented for > general iSCSI login, authentication and text processing. It > is basically > just another text command that has very wide spread utility. > > 2. The fact that a discovery session, where SendTargets can > be performed, > uses the exact same authentication and login mechanisms is a > fundamental > benefit of the scheme. Alternatives will require their own (albeit > similar) > implementations for authentication. Deploying, configuring > and maintaining > AAA infrastructure has always been a stumbling block for customers and > complicating this with additional protocols and clients will not help > matters. > > 3. The complication of an iterator can be avoided if we > restrict the usage > of SendTargets to a session on a well-known target or clearly > document the > potential issues of blocking a connection in an > implementation. However, I > would support the definition of an iterator if there is > consensus. This is > not a show-stopper. > > 4. Splitting SendTargets into multiple commands (ReportTargets and > ReportPortalGroups) seems unnecessary and not relevant. I > have not heard > the entire discussion surrounding ReportPortalGroups, but it > would seem > that > this information would be better reported via the MIB or at > least should be > made available via the MIB. Even if there is a need for such > a command > then > it appears to be an entirely separate issue. > > 5. Enhancing SendTarget responses to include additional information > regarding certificates or boot related information appears to > be in the > category of 'creeping elegance' and does not to need to be > considered at > this time. Facilities will be in place to establish the > session needed to > perform SendTargets anyway, and returning additional information that > allows > one to avoid using these facilities is purely an optimization. > > 6. An example of SendTarget's power and simplicity (as-is) is > the ability > to > use it to create a SendTargets tree as you've described. > There is really > nothing that "needs" to be changed from the current scheme to > support this > behavior. This is a perfect example of how the very same > mechanism can be > used to 'scale' in environments from very small plug-and-play > workgroups to > a large centrally administered, highly secured, enterprises. > > So, from an expediency and philosophical perspective I > believe we should > implement SendTargets now and contain the number of proposed > changes to > keep > it as simply as possible. We should NOT move this to another > document, > since it is really just another text command, but a very > powerful one at > that. > > Paul > > +--------------------------+----------------------------+ > + Paul Congdon + Email: paul_congdon@hp.com + > + Hewlett Packard Company + Mail Stop: 5662 + > + HP ProCurve Networking + Phone: (916) 785-5753 + > + 8000 Foothills Blvd + Fax: (916) 785-5949 + > + Roseville, CA 95747 + Mobile: (916) 765-4056 + > +--------------------------+----------------------------+ > > > > > From owner-ips@ece.cmu.edu Tue Jun 5 19:26:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01451 for ; Tue, 5 Jun 2001 19:26:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f55LUfC05882 for ips-outgoing; Tue, 5 Jun 2001 17:30:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f55LUdg05878 for ; Tue, 5 Jun 2001 17:30:40 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id XAA149630 for ; Tue, 5 Jun 2001 23:30:33 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.8.8m3/NCO v4.96) with SMTP id XAA99066 for ; Tue, 5 Jun 2001 23:29:31 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A62.00760D4B ; Tue, 5 Jun 2001 23:29:26 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 6 Jun 2001 00:35:45 +0300 Subject: RE: iSCSI Discovery and SendTargets or Expediency vs. Planning Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, Just to be sure that I understood well your line of thought: - solution 1 is good because it is expedient (easy to do!) -future extensions should not be considered at this time (they will become expedient in their own time!) -commonality with other discovery protocols has no appeal (you do net mention it) I would like to point out that the SendTargets should not be considered as a standalone thing. It will (has to) be supported by a management infrastructure that: - has to install the names -check and invalidate them as needed etc. Should we start also adding ReceiveTargets to install the names in the targets (it very easy to add!). And how about certificates, ACLs etc (we could accommodate those too1). Julo "CONGDON,PAUL (HP-Roseville,ex1)" on 05-06-2001 21:57:32 Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Mark Bakke'" , IPS cc: Subject: RE: iSCSI Discovery and SendTargets Mark and NDT team, Nice write-up of your discussions. In summary I would like to strongly support the position of option 1 in your memo, which is keeping SendTargets as-is with the few minor modifications to support aggregation tags, but not much else. We do need to contain the scope of SendTargets, but removing it from the spec would be a tremendous loss of a very simply yet powerful feature. My supporting comments are as follows: 1. Keeping SendTargets basically as-is, but with the addition of aggregation tags is a very small increment over what must already be implemented for general iSCSI login, authentication and text processing. It is basically just another text command that has very wide spread utility. 2. The fact that a discovery session, where SendTargets can be performed, uses the exact same authentication and login mechanisms is a fundamental benefit of the scheme. Alternatives will require their own (albeit similar) implementations for authentication. Deploying, configuring and maintaining AAA infrastructure has always been a stumbling block for customers and complicating this with additional protocols and clients will not help matters. 3. The complication of an iterator can be avoided if we restrict the usage of SendTargets to a session on a well-known target or clearly document the potential issues of blocking a connection in an implementation. However, I would support the definition of an iterator if there is consensus. This is not a show-stopper. 4. Splitting SendTargets into multiple commands (ReportTargets and ReportPortalGroups) seems unnecessary and not relevant. I have not heard the entire discussion surrounding ReportPortalGroups, but it would seem that this information would be better reported via the MIB or at least should be made available via the MIB. Even if there is a need for such a command then it appears to be an entirely separate issue. 5. Enhancing SendTarget responses to include additional information regarding certificates or boot related information appears to be in the category of 'creeping elegance' and does not to need to be considered at this time. Facilities will be in place to establish the session needed to perform SendTargets anyway, and returning additional information that allows one to avoid using these facilities is purely an optimization. 6. An example of SendTarget's power and simplicity (as-is) is the ability to use it to create a SendTargets tree as you've described. There is really nothing that "needs" to be changed from the current scheme to support this behavior. This is a perfect example of how the very same mechanism can be used to 'scale' in environments from very small plug-and-play workgroups to a large centrally administered, highly secured, enterprises. So, from an expediency and philosophical perspective I believe we should implement SendTargets now and contain the number of proposed changes to keep it as simply as possible. We should NOT move this to another document, since it is really just another text command, but a very powerful one at that. Paul +--------------------------+----------------------------+ + Paul Congdon + Email: paul_congdon@hp.com + + Hewlett Packard Company + Mail Stop: 5662 + + HP ProCurve Networking + Phone: (916) 785-5753 + + 8000 Foothills Blvd + Fax: (916) 785-5949 + + Roseville, CA 95747 + Mobile: (916) 765-4056 + +--------------------------+----------------------------+ From owner-ips@ece.cmu.edu Tue Jun 5 20:56:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02292 for ; Tue, 5 Jun 2001 20:56:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f55Msvn11470 for ips-outgoing; Tue, 5 Jun 2001 18:54:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f55Msug11466 for ; Tue, 5 Jun 2001 18:54:56 -0400 (EDT) Received: from cs.uchicago.edu (h005018031eeb.ne.mediaone.net [24.91.83.49]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f55Mst615136 for ; Tue, 5 Jun 2001 18:54:55 -0400 (EDT) Message-Id: <200106052254.f55Mst615136@chmls20.mediaone.net> To: ips@ece.cmu.edu Subject: Re: Section 4.1 Login Phase Start In-Reply-To: Message from "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" of "Tue, 05 Jun 2001 17:45:32 BST." <0B9A57FF1D57D411B47500D0B73E5CC101E7A737@dickens.bri.hp.com> References: <0B9A57FF1D57D411B47500D0B73E5CC101E7A737@dickens.bri.hp.com> Date: Tue, 05 Jun 2001 18:52:44 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk Matthew, > Either it is optional and the target should not ignore it (e.g. check the > name against the existing session), or it should not be sent at all. I couldn't agree more. A third position would be that it be required, AND checked. Frankly, I see little point in making it optional. If I'm an initiator, and it's optional, I'm not going to send it, because it's one less error condition (that I may have created) I have to specifically address in the response. If we believe there is an important and likely programming error (it doesn't detect a regular, operational condition, right?) vulnerability that is detected by checking the target name on following logins, we should require that they always be sent. Personally, I don't see such a vulnerability. This argues for requiring that target name NOT be sent on following logins. That is what I suggested, once upon a time. Whatever we chose, optional doesn't really seem like a useful position. Steph From owner-ips@ece.cmu.edu Tue Jun 5 22:18:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04281 for ; Tue, 5 Jun 2001 22:18:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f560VSp17424 for ips-outgoing; Tue, 5 Jun 2001 20:31:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f560VQg17420 for ; Tue, 5 Jun 2001 20:31:27 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel2.hp.com (Postfix) with ESMTP id 3361518FB; Tue, 5 Jun 2001 17:31:26 -0700 (PDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 3B41C1F509; Tue, 5 Jun 2001 17:29:49 -0700 (PDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 20:31:24 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A090C8@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'julian_satran@il.ibm.com'" , ips@ece.cmu.edu Subject: RE: iSCSI Discovery and SendTargets or Expediency vs. Planning Date: Tue, 5 Jun 2001 20:31:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julo, > I would like to point out that the SendTargets should not be considered as > a standalone thing. > It will (has to) be supported by a management infrastructure that: > > - has to install the names > -check and invalidate them as needed A target device with a network interface already has to have a "management infrastructure", regardless of whether or not SendTargets is part of the iSCSI protocol. The IP-ness of the device requires that the user be able to configure IP addresses, masks, gateway's, DNS servers (possibly) and there's also the configuration of a target name, should a user want to change the target's default name. -Marj From owner-ips@ece.cmu.edu Wed Jun 6 00:23:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07139 for ; Wed, 6 Jun 2001 00:23:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f562QuZ24800 for ips-outgoing; Tue, 5 Jun 2001 22:26:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.6.9.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f562Qrg24795 for ; Tue, 5 Jun 2001 22:26:53 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id BC02C13E8 for ; Tue, 5 Jun 2001 20:26:52 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 64B5ED9 for ; Tue, 5 Jun 2001 20:26:52 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id TAA01103 for ; Tue, 5 Jun 2001 19:26:51 -0700 (PDT) Received: from agilent.com (cos1nai132035.cos.agilent.com [141.184.132.35]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA5418 for ; Tue, 5 Jun 2001 19:26:48 -0700 Message-ID: <3B1D84E0.587199E3@agilent.com> Date: Tue, 05 Jun 2001 18:18:24 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: More draft-06 comments References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit julian_satran@il.ibm.com wrote: > ++++ although this text has no ambiguity there is still a raging debate > between the proponents of an always explicit response (Matt and - in some > covoluted form Steph - and those like Steve Senum who whould like a hiatus > signaling a default. The current text let you set none by default. This > can be changed by removing the " and MAY be selected by omission... " +++ I would like the "and MAY be selected by omission..." removed. > 2.1 - Need to say that padding is not included in the > length field. Should also specify a MUST for the pad byte value. > > +++ the PDU outline in 2.2 is clear enough. It's obviously not clear enough - you wrote it so you understand it. You want to make it clear to someone just picking up the spec. > The negative specification > (does not include like) > is unbounded. I have no idea what the above means. > +++ I have a tool problem here ... and was unable to fix it up to now > (Word!) +++ use a real tool, not a toy! :) -Matt From owner-ips@ece.cmu.edu Wed Jun 6 00:26:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07174 for ; Wed, 6 Jun 2001 00:26:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f562QrH24793 for ips-outgoing; Tue, 5 Jun 2001 22:26:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.6.9.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f562Qpg24789 for ; Tue, 5 Jun 2001 22:26:51 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 5A79013EB for ; Tue, 5 Jun 2001 20:26:50 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id E6453D9 for ; Tue, 5 Jun 2001 20:26:49 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id TAA01099 for ; Tue, 5 Jun 2001 19:26:49 -0700 (PDT) Received: from agilent.com (cos1nai132035.cos.agilent.com [141.184.132.35]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA5413 for ; Tue, 5 Jun 2001 19:26:44 -0700 Message-ID: <3B1D7D4B.110FEC92@agilent.com> Date: Tue, 05 Jun 2001 17:46:03 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: Logout command, or The Initiator's new close() References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think we must dictate implementation. Anything other than specifying how the close is to work mean interoperability problems. I vote for Mark's first choice: > The most straight-forward choice might be: > > Initiator sends the logout request, and simply waits for > the response without closing the connection. The target > sends the logout response, and closes its end of the > connection. The initiator receives the logout response, > and the FIN from the target, and closes its end of the > connection. That way, if there are outstanding I/Os that need to be completed or errors that must be communicated, the appropriate communication can be completed before the TCP connections are destroyed. -Matt Wakeley Agilent Technologies julian_satran@il.ibm.com wrote: > > Mark, > > I don't think that we should dictate implementation. > As we assume that nothing is sent after Logout (should we spell this out) > and we have to wait > for the logout response we can do a half close and wait or wait and do a > full close after seeing the Logout response. > The first is faster the second is simpler. > > Regards, > Julo > > Mark Bakke on 26-05-2001 00:43:30 > > Please respond to Mark Bakke > > To: IPS > cc: > Subject: iSCSI: Logout command, or The Initiator's new close() > > Section 2.14 (the logout command) is not clear on how the logout > command and response work when the logout request is send on a > connection for which it requests termination. We should probably > specify the TCP close behavior of the initiator and target. > > The initiator can send the logout request, and either close > the current connection, half-close the connection and wait > for the logout response (like HTTP/1.0), or leave it open, > and close the connection upon receiving the response or the > FIN from the target. > > Upon receiving the logout request, the target can either > close the connection immediately, send the logout response > and then close the connection, or send the logout response > and wait for the initiator to close the connection upon its > receipt of the logout response. > > Logout would work best if the initiators and targets all did > this in the same manner, choosing one of the above behaviors > for the initiator, and a compatible one for the target. > > The most straight-forward choice might be: > > Initiator sends the logout request, and simply waits for > the response without closing the connection. The target > sends the logout response, and closes its end of the > connection. The initiator receives the logout response, > and the FIN from the target, and closes its end of the > connection. > > Any opinions on whether this is best? This choice does not > require the initiator to know that the connection that is being > closed is the one it sent the logout response on, but does > require the target to send the logout response before it actually > closes the connection. > > Another behavior that might work would be to say that the target > closes all of its connections and does cleanup before sending the > logout response, and if the connection on which the request came > in is gone, it does not send a response. An initiator whose > connection is closed after sending the logoout request can assume > that the request worked. > > Anyway, I think that it would be good to clarify this. > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Wed Jun 6 01:10:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07777 for ; Wed, 6 Jun 2001 01:10:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f563Aw227590 for ips-outgoing; Tue, 5 Jun 2001 23:10:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f563Aug27582 for ; Tue, 5 Jun 2001 23:10:56 -0400 (EDT) Received: from ahganemw2k ([10.21.58.85] (may be forged)) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id XAA04134 for ; Tue, 5 Jun 2001 23:10:49 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iSCSI - opcodes Date: Tue, 5 Jun 2001 22:09:44 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I am not sure what decision was taken on this, but I would also vote for having the direction bit as the MSB (bit-5) in the opcode. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Monday, May 28, 2001 6:54 AM > To: ips@ece.cmu.edu > Subject: RE: iSCSI - opcodes > > > > > The new codes are in the 07 draft. Although I've put back the bit that > shows direction I seriously doubt that > it's original purpose (to make life easier for analyzers) is as > relevant as > it was. > > Julo > > "Martin, Nick" on 01-05-2001 01:48:00 > > Please respond to "Martin, Nick" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: RE: iSCSI - opcodes > > > > > Julian, > > I was not among the incensed. I would say puzzled. Although the bit may > not be not critical to initiators or targets who presumably know what they > are, it is handy at least for network analyzer displays. > > Since it now still consumes a bit, I would have made it the MSB of the > Opcode field as in previous drafts (currently bit 5 or 0x20). However I > can > cope with your selection ((Opcode & 0x3e)>>1) :). > > The 2F reject instead of 3F (or 1f) for reject was another puzzler. > Presumably you wanted a fence between unused reserved opcodes and vendor > specific codes. > > Thanks, > Nick Martin > > -----Original Message----- > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] > Sent: Friday, April 27, 2001 12:38 AM > To: ips@ece.cmu.edu > Cc: matt_wakeley@agilent.com > Subject: iSCSI - opcodes > > > > > Fellow iSCSI fans, > > Some were incesed by the lak of a "direction bit" in the opcodes in draft > 06. > Here is an attempt to a new list (having a bit for direction back - as the > LSB ). > To gain some reserved space I've curtailed the vendo-specific > codes to 4 in > each direction. > > > Please comment, > Julo > > 1.1.1.1 Opcode > > The Opcode indicates what type of iSCSI PDU the header encapsulates. > > The Opcodes are divided into two categories: initiator opcodes and > target opcodes. Initiator opcodes are in PDUs sent by the initiators > (request PDUs), and target opcodes are in PDUs sent by the target > (response PDUs). > > Initiators MUST NOT use target opcodes and targets MUST NOT use > initiator opcodes. > > Valid initiator opcodes defined in this specification are: > > > 0x00 NOP-Out (from initiator to target) > 0x02 SCSI Command (encapsulates a SCSI Command Descriptor Block) > 0x04 SCSI Task Management Command > 0x06 Login Command > 0x08 Text Command > 0x0a SCSI Data-out (for WRITE operations) > 0x0c Logout Command > 0x10 SNACK Request > > Valid target opcodes are: > > > 0x01 NOP-In (from target to initiator) > 0x03 SCSI Response (contains SCSI status and possibly sense > information or other response information) > 0x05 SCSI Task Management Response > 0x07 Login Response > 0x09 Text Response > 0x0b SCSI Data-in (for READ operations) > 0x0d Logout Response > 0x11 Ready To Transfer (R2T - sent by target to initiator when it is > ready to receive data from initiator) > 0x13 Asynchronous Message (sent by target to initiator to indicate > certain special conditions) > 0x2f Reject > > Initiator opcodes 0x38, 0x3a, 0x3c and 0x3e and target opcodes 0x39, > 0x3b, 0x3d and 0x3f are vendor specific codes. > > > > > From owner-ips@ece.cmu.edu Wed Jun 6 08:35:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28002 for ; Wed, 6 Jun 2001 08:35:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56AeSp03510 for ips-outgoing; Wed, 6 Jun 2001 06:40:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56AeQg03505 for ; Wed, 6 Jun 2001 06:40:26 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA140440 for ; Wed, 6 Jun 2001 12:40:19 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.96) with SMTP id MAA30692 for ; Wed, 6 Jun 2001 12:40:19 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A63.003A8121 ; Wed, 6 Jun 2001 12:39:01 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 6 Jun 2001 05:21:28 +0300 Subject: RE: iSCSI Discovery and SendTargets or Expediency vs. Planning Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk ---------------------- Forwarded by Julian Satran/Haifa/IBM on 06-06-2001 05:21 --------------------------- Julian Satran 06-06-2001 00:35 To: ips@ece.cmu.edu cc: From: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI Discovery and SendTargets or Expediency vs. Planning (Document link: Julian Satran - Mail) Paul, Just to be sure that I understood well your line of thought: - solution 1 is good because it is expedient (easy to do!) -future extensions should not be considered at this time (they will become expedient in their own time!) -commonality with other discovery protocols has no appeal (you do net mention it) I would like to point out that the SendTargets should not be considered as a standalone thing. It will (has to) be supported by a management infrastructure that: - has to install the names -check and invalidate them as needed etc. Should we start also adding ReceiveTargets to install the names in the targets (it very easy to add!). And how about certificates, ACLs etc (we could accommodate those too1). Julo "CONGDON,PAUL (HP-Roseville,ex1)" on 05-06-2001 21:57:32 Please respond to "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Mark Bakke'" , IPS cc: Subject: RE: iSCSI Discovery and SendTargets Mark and NDT team, Nice write-up of your discussions. In summary I would like to strongly support the position of option 1 in your memo, which is keeping SendTargets as-is with the few minor modifications to support aggregation tags, but not much else. We do need to contain the scope of SendTargets, but removing it from the spec would be a tremendous loss of a very simply yet powerful feature. My supporting comments are as follows: 1. Keeping SendTargets basically as-is, but with the addition of aggregation tags is a very small increment over what must already be implemented for general iSCSI login, authentication and text processing. It is basically just another text command that has very wide spread utility. 2. The fact that a discovery session, where SendTargets can be performed, uses the exact same authentication and login mechanisms is a fundamental benefit of the scheme. Alternatives will require their own (albeit similar) implementations for authentication. Deploying, configuring and maintaining AAA infrastructure has always been a stumbling block for customers and complicating this with additional protocols and clients will not help matters. 3. The complication of an iterator can be avoided if we restrict the usage of SendTargets to a session on a well-known target or clearly document the potential issues of blocking a connection in an implementation. However, I would support the definition of an iterator if there is consensus. This is not a show-stopper. 4. Splitting SendTargets into multiple commands (ReportTargets and ReportPortalGroups) seems unnecessary and not relevant. I have not heard the entire discussion surrounding ReportPortalGroups, but it would seem that this information would be better reported via the MIB or at least should be made available via the MIB. Even if there is a need for such a command then it appears to be an entirely separate issue. 5. Enhancing SendTarget responses to include additional information regarding certificates or boot related information appears to be in the category of 'creeping elegance' and does not to need to be considered at this time. Facilities will be in place to establish the session needed to perform SendTargets anyway, and returning additional information that allows one to avoid using these facilities is purely an optimization. 6. An example of SendTarget's power and simplicity (as-is) is the ability to use it to create a SendTargets tree as you've described. There is really nothing that "needs" to be changed from the current scheme to support this behavior. This is a perfect example of how the very same mechanism can be used to 'scale' in environments from very small plug-and-play workgroups to a large centrally administered, highly secured, enterprises. So, from an expediency and philosophical perspective I believe we should implement SendTargets now and contain the number of proposed changes to keep it as simply as possible. We should NOT move this to another document, since it is really just another text command, but a very powerful one at that. Paul +--------------------------+----------------------------+ + Paul Congdon + Email: paul_congdon@hp.com + + Hewlett Packard Company + Mail Stop: 5662 + + HP ProCurve Networking + Phone: (916) 785-5753 + + 8000 Foothills Blvd + Fax: (916) 785-5949 + + Roseville, CA 95747 + Mobile: (916) 765-4056 + +--------------------------+----------------------------+ From owner-ips@ece.cmu.edu Wed Jun 6 08:37:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28052 for ; Wed, 6 Jun 2001 08:37:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56AeN703503 for ips-outgoing; Wed, 6 Jun 2001 06:40:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56AeLg03497 for ; Wed, 6 Jun 2001 06:40:21 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA143670 for ; Wed, 6 Jun 2001 12:40:14 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m3/NCO v4.96) with SMTP id MAA30688 for ; Wed, 6 Jun 2001 12:40:09 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A63.003A81BC ; Wed, 6 Jun 2001 12:39:03 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 6 Jun 2001 05:26:53 +0300 Subject: RE: iSCSI Discovery and SendTargets or Expediency vs. Planning Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie, This is exactly my point. SendTargets has to be part of the management infrastructure and not the iSCSI operational structure. It can live and thrive there. Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" on 06-06-2001 03:31:21 Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI Discovery and SendTargets or Expediency vs. Planning Julo, > I would like to point out that the SendTargets should not be considered as > a standalone thing. > It will (has to) be supported by a management infrastructure that: > > - has to install the names > -check and invalidate them as needed A target device with a network interface already has to have a "management infrastructure", regardless of whether or not SendTargets is part of the iSCSI protocol. The IP-ness of the device requires that the user be able to configure IP addresses, masks, gateway's, DNS servers (possibly) and there's also the configuration of a target name, should a user want to change the target's default name. -Marj From owner-ips@ece.cmu.edu Wed Jun 6 13:16:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05840 for ; Wed, 6 Jun 2001 13:16:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56EuWU20497 for ips-outgoing; Wed, 6 Jun 2001 10:56:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56EuUg20487 for ; Wed, 6 Jun 2001 10:56:30 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 9F727171 for ; Wed, 6 Jun 2001 16:56:17 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id PAA13394 for ; Wed, 6 Jun 2001 15:56:16 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Wed, 06 Jun 2001 15:56:15 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 15:56:15 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A739@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: RE: Unsolicited Data. Date: Wed, 6 Jun 2001 15:35:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The current spec states that the F bit is "set to 1 when the immediate data that accompany the command are all the data associated with this command. It is an error if the Length and Expected Length do not match and this bit is set to 1". I interpret this as there is no more data to follow and not that the initiator has opted not to use the unsolicited data feature. Therefore the spec needs to be modified to indicate that if unsolicited data has been negotiated (i.e. InitialR2T=no), then the initiator MUST send unsolicited data of length = min( FirstBurstSize, ExpectedTransferLength ) minus any immediate data sent). Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Ayman Ghanem [mailto:aghanem@cisco.com] Sent: Tuesday, June 05, 2001 6:31 PM To: ips@ece.cmu.edu Subject: RE: Unsolicited Data. If the initiator decides not to send immediate or unsolicited data when it has negotiated to do so, then the initiator must set the F-bit in the command PDU. This prompts the target to send R2T. I still agree that the spec should indicate that the initiator MUST use the resources it has negotiated. If it has negotiated the option to send immediate data or unsolicited data then it should do that to the limits allowed. If it has negotiated a PDU length, it must not send data PDUs less than the negotiated limit except for last one. While most implementation may do that for performance reasons, I would prefer defining this in the spec. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > Sent: Tuesday, June 05, 2001 11:58 AM > To: 'ips@ece.cmu.edu' > Subject: Unsolicited Data. > > > I'm not sure if this has been discussed before but it is causing some > confusion. The statement below implies that if immediate data has been > negotiated then the initiator MAY use it. > > "If ImmediateData is set to no and InitialR2T is set to no then the > initiator MUST NOT send unsolicited immediate data but MAY send one > unsolicited burst of Data-OUT PDUs." > > Therefore the target must wait for the initial burst of unsolicited data > before issuing the first R2T (if there is subsequent data). If the > initiator decides not to send it then the target must timeout and > issue the > R2T for the initial data. Can the spec be changed to state that if > unsolicited data has been negotiated, then the initiator MUST use it. > > Thanks > > Matthew Burbridge > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > From owner-ips@ece.cmu.edu Wed Jun 6 15:09:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07973 for ; Wed, 6 Jun 2001 15:09:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56GnXw29550 for ips-outgoing; Wed, 6 Jun 2001 12:49:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56GnVg29546 for ; Wed, 6 Jun 2001 12:49:31 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-139.cisco.com [161.44.68.139]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA22919 for ; Wed, 6 Jun 2001 12:49:25 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: Unsolicited Data. Date: Wed, 6 Jun 2001 11:48:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC101E7A739@dickens.bri.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit That section was modified. Julian posted the revised text here: http://ips.pdl.cs.cmu.edu/mail/msg04647.html -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > Sent: Wednesday, June 06, 2001 9:36 AM > To: 'ips@ece.cmu.edu' > Subject: RE: Unsolicited Data. > > > > The current spec states that the F bit is "set to 1 when the > immediate data > that accompany the command are all the data associated with this > command. It > is an error if the Length and Expected Length do not match and this bit is > set to 1". > > I interpret this as there is no more data to follow and not that the > initiator has opted not to use the unsolicited data feature. > Therefore the > spec needs to be modified to indicate that if unsolicited data has been > negotiated (i.e. InitialR2T=no), then the initiator MUST send unsolicited > data of length = min( FirstBurstSize, ExpectedTransferLength ) minus any > immediate data sent). > > Matthew Burbridge > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > > -----Original Message----- > From: Ayman Ghanem [mailto:aghanem@cisco.com] > Sent: Tuesday, June 05, 2001 6:31 PM > To: ips@ece.cmu.edu > Subject: RE: Unsolicited Data. > > > If the initiator decides not to send immediate or unsolicited data when it > has negotiated to do so, then the initiator must set the F-bit in the > command PDU. This prompts the target to send R2T. > > I still agree that the spec should indicate that the initiator > MUST use the > resources it has negotiated. If it has negotiated the option to send > immediate data or unsolicited data then it should do that to the limits > allowed. If it has negotiated a PDU length, it must not send data > PDUs less > than the negotiated limit except for last one. While most > implementation may > do that for performance reasons, I would prefer defining this in the spec. > > -Ayman > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Sent: Tuesday, June 05, 2001 11:58 AM > > To: 'ips@ece.cmu.edu' > > Subject: Unsolicited Data. > > > > > > I'm not sure if this has been discussed before but it is causing some > > confusion. The statement below implies that if immediate data has been > > negotiated then the initiator MAY use it. > > > > "If ImmediateData is set to no and InitialR2T is set to no then the > > initiator MUST NOT send unsolicited immediate data but MAY send one > > unsolicited burst of Data-OUT PDUs." > > > > Therefore the target must wait for the initial burst of unsolicited data > > before issuing the first R2T (if there is subsequent data). If the > > initiator decides not to send it then the target must timeout and > > issue the > > R2T for the initial data. Can the spec be changed to state that if > > unsolicited data has been negotiated, then the initiator MUST use it. > > > > Thanks > > > > Matthew Burbridge > > NIS-Bristol > > Hewlett Packard > > Telnet: 312 7010 > > E-mail: matthewb@bri.hp.com > > > > > From owner-ips@ece.cmu.edu Wed Jun 6 15:12:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08024 for ; Wed, 6 Jun 2001 15:12:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56H1Dn00519 for ips-outgoing; Wed, 6 Jun 2001 13:01:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56H1Bg00514 for ; Wed, 6 Jun 2001 13:01:12 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel2.hp.com (Postfix) with ESMTP id C31911C1C; Wed, 6 Jun 2001 10:01:10 -0700 (PDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 0FAA11F511; Wed, 6 Jun 2001 09:59:33 -0700 (PDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 13:01:09 -0400 Message-ID: <499DC368E25AD411B3F100902740AD6507778CA6@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: julian_satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI Discovery and SendTargets or Expediency vs. Planning Date: Wed, 6 Jun 2001 13:01:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I'm sensing sarcasm here... If so, lets take the jokes offline. People have better things to do. If not, then consider my responses below... Nothing is ever "easy to do" as you well know. > > > Paul, > > Just to be sure that I understood well your line of thought: > > - solution 1 is good because it is expedient (easy to do!) I don't believe that was the crux of my message. While option 1 is expedient, it more importantly preserves the utility of the SendTargets functionality within the current spec. As I described, most of what you need to support SendTargets will have to be implemented for general iSCSI login, authentication and command text processing. It will be easy for customers to make good use of this feature in both small and large environments. > -future extensions should not be considered at this time > (they will become > expedient in their own time!) We should consider future extensions to a point, but we are all looking forward to a initial stable version of this spec, and we should make sure we are covering the most common and important cases. Of course this is a judgement call. > -commonality with other discovery protocols has no appeal (you do net > mention it) > Certainly we should not re-invent the wheel, but there is a fine line between using a plethora of protocols and associated management to cover a space and making a small augmentation to the base protocol to fill a basic need. My opinion is that SendTargets falls on the side of the line to include in the iSCSI spec. > I would like to point out that the SendTargets should not be > considered as > a standalone thing. > It will (has to) be supported by a management infrastructure that: > > - has to install the names > -check and invalidate them as needed > > etc. > Very true, but there is great flexibility in how this is done without changing the existing specification or creating a new one. This may be done on the targets themselves, on master targets, independent management servers or no-where at all. > Should we start also adding ReceiveTargets to install the names in the > targets (it very easy to add!). > And how about certificates, ACLs etc (we could accommodate > those too1). > Now I'm sure I'm hearing sarcasm... This is device management. While we are at it, why not consider adding a command to set the baud-rate on the target serial port... Paul From owner-ips@ece.cmu.edu Wed Jun 6 16:54:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09047 for ; Wed, 6 Jun 2001 16:54:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56IZVs07950 for ips-outgoing; Wed, 6 Jun 2001 14:35:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e32.bld.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56IZTg07945 for ; Wed, 6 Jun 2001 14:35:29 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e32.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA49100 for ; Wed, 6 Jun 2001 14:36:24 -0400 Received: from f4n49e (d03nm065h.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1/NCO v4.96.1.0) with ESMTP id f56IY9b187112 for ; Wed, 6 Jun 2001 12:34:09 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Send Targets and Report Portal Groups To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 6 Jun 2001 11:34:01 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/06/2001 12:34:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk iSCSI Team, I would like to propose the following approaches to address the issues of Send-Targets, and Report Portal Groups. The way Send-Targets has evolved, which is now a separate interaction with its own Login, makes it seem like the same function can be rationally performed by current Discovery Functions in SLP or iSNS. Now this is not completely correct, but close enough for me to propose a compromise. Before I state the compromise let me address the items that are current concerns with an SLP or iSNS approach of replacing Send-Targets. 1. The current SLP Open Source does not do a Unicast to ask for the information. This is not a shortcoming of the SLP protocol, just the current API/Implementation. Mark Bakke has made a Hack into the Open Source and believes that it will work just fine, and also thinks he has support for that approach from the Owners of the Open Source. However, there is still some uncertainty here, which will only be cleared up with time and multiple implementations. 2. There are separate Authentication models followed by SLP/iSNS as opposed to iSCSI. Therefore, any Initiator attempting to do SLP or iSNS for basic discovery, needs to address two Authentication models, the discovery method's authentication approach, and iSCSI's. 3. In small installations it is not clear that there will be an SLP or iSNS setup on which to leverage this approach. Now, I am cretin there will be arguments about the importance of any of those points, the issue is -- the uncertainty of favorable results. I am of the belief that it maybe worth the effort to move in the direction of "atrophying" the Send Targets Command and Processes. That is, it serves a current and valuable function, of which a favorable replacement, though probable, is uncertain at this time. So we should begin moving in the direction of the SLP/iSNS approach, but without additional care and feeding of Send Targets. An approach to this is to move the Send Target Command and Processes, into an Annex of the main iSCSI protocol document. As such it will be a current requirement for implementation, but it will also be clear that we believe it may be eliminated in version 2 of the iSCSI document (when ever that occurs) and is not something in which feature creep will be permitted. I think the above approach will satisfy the folks that have been building and testing various product approaches that depend on Send Targets, and yet give them time to move to an SLP or iSNS type approach as the concerns specified above are worked out. It is also possible that in the future, we will find that we are fundamentally wrong in some of our key assumptions, and that Version 2 may move it back into the main document. That would also be acceptable, because I do not believe it would happen lightly, and would have to have great reasoning and logic behind such a move. Now, I would like to address the Report Portal Groups. I do not place this in the same category as Send Targets. It is a specific query about the environment of the specific session in which the command is issued. It is analogous to Report LUNs, and querying Mode Pages. For those of you that have not been following this closely, the Report Portal Groups, is a command that responds with the IP addresses that can be used by the initiator of the current session, to add additional connections to the current session (and thereby support Multiple Connections per Session). It is specific to its own session, and not to some general management item. Some might say that this too could be discovered by some management function, however, that could also be true about many of the Mode Page setting also. In my opinion the Portal Groups will probably be "wired in" by the Storage Controller vendor and not be something that is settable by the administrator. In fact with Report Portal Groups, being part of the base protocol, the SLP/iSNS (or the Send Targets Command) will not have to include the portal group identification/tagging in its responses, thus simplifying them. So as part of my proposed compromise I recommend that we put "Report Portal Groups" into the main iSCSI Protocol Document, like any of the other iSCSI Commands, and move the Send-Targets command to an Annex as specified above. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Wed Jun 6 18:21:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09959 for ; Wed, 6 Jun 2001 18:21:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56JiGp13356 for ips-outgoing; Wed, 6 Jun 2001 15:44:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56JiEg13350 for ; Wed, 6 Jun 2001 15:44:14 -0400 (EDT) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel1.hp.com (Postfix) with ESMTP id 194CC14CF for ; Wed, 6 Jun 2001 12:44:13 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 85FE51F50D for ; Wed, 6 Jun 2001 12:43:13 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 12:44:12 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A090CB@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI Discovery and SendTargets or Expediency vs. Planning Date: Wed, 6 Jun 2001 12:44:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk *My point* = the fact that configuration information needs to be managed does not dictate the way information is exchanged. We are already exchanging some "configuration information" in the text commands so that the iSCSI endpoints may communicate. Are you saying we must remove all text commands, since they are also "things that are part of the managed data"? There have been extensions to the text commands - are we also tempted to add "configure" text command options for them? We have to exercise judgement on all issues, we all agree. -Marj > Marjorie, > > This is exactly my point. SendTargets has to be part of the management > infrastructure and not the iSCSI operational structure. It > can live and > thrive there. > > Julo > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" on > 06-06-2001 03:31:21 > > Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: RE: iSCSI Discovery and SendTargets or Expediency > vs. Planning > > > > > Julo, > > > I would like to point out that the SendTargets should not > be considered > as > > a standalone thing. > > It will (has to) be supported by a management infrastructure that: > > > > - has to install the names > > -check and invalidate them as needed > > A target device with a network interface already has to have > a "management > infrastructure", regardless of whether or not SendTargets is > part of the > iSCSI protocol. The IP-ness of the device requires that the > user be able > to > configure IP addresses, masks, gateway's, DNS servers (possibly) and > there's > also the configuration of a target name, should a user want > to change the > target's default name. > > -Marj > > > From owner-ips@ece.cmu.edu Wed Jun 6 19:42:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10685 for ; Wed, 6 Jun 2001 19:42:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56Ldc122647 for ips-outgoing; Wed, 6 Jun 2001 17:39:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56Ldbg22643 for ; Wed, 6 Jun 2001 17:39:37 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA69262 for ; Wed, 6 Jun 2001 16:34:01 -0500 Received: from f4n49e (d03nm065h.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1/NCO v4.96.1.0) with ESMTP id f56Lavb200652 for ; Wed, 6 Jun 2001 15:36:57 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Send Targets and Report Portal Groups To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 6 Jun 2001 14:36:51 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/06/2001 03:36:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Perhaps some of my typing finger checks are actually more correct then the intended text. (Some times even finger checks pass spell check.) . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com ---------------------- Forwarded by John Hufferd/San Jose/IBM on 06/06/2001 02:33 PM --------------------------- Tom_Maufer@3com.com on 06/06/2001 01:20:24 PM To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: iSCSI: Send Targets and Report Portal Groups John-- >Now, I am cretin there will be arguments about the importance of ^^^^^^ >any of those points, the issue is -- the uncertainty of favorable >results. I am *certain* that you aren't a *cretin*. :-) Cheers, Tom From owner-ips@ece.cmu.edu Wed Jun 6 20:38:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11058 for ; Wed, 6 Jun 2001 20:38:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56MwaK27929 for ips-outgoing; Wed, 6 Jun 2001 18:58:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56MwXg27911 for ; Wed, 6 Jun 2001 18:58:33 -0400 (EDT) Received: from daniel ([213.10.179.111]) by smtp03.wxs.nl (Netscape Messaging Server 4.05) with SMTP id GEJ6HE00.G2N; Thu, 7 Jun 2001 00:58:26 +0200 Message-ID: <003001c0eedd$34a67080$9600000a@daniel> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: References: Subject: Re: Unsolicited Data. Date: Thu, 7 Jun 2001 01:05:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, All that is said below is ok but I cannot understand one thing here ----- why would initiator choose not to send unsolicited immediate data when it has negotiated for IntialR2T= Yes?? Sanjeev ----- Original Message ----- From: "Ayman Ghanem" To: Sent: Wednesday, June 06, 2001 6:48 PM Subject: RE: Unsolicited Data. > That section was modified. Julian posted the revised text here: > > http://ips.pdl.cs.cmu.edu/mail/msg04647.html > > -Ayman > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Sent: Wednesday, June 06, 2001 9:36 AM > > To: 'ips@ece.cmu.edu' > > Subject: RE: Unsolicited Data. > > > > > > > > The current spec states that the F bit is "set to 1 when the > > immediate data > > that accompany the command are all the data associated with this > > command. It > > is an error if the Length and Expected Length do not match and this bit is > > set to 1". > > > > I interpret this as there is no more data to follow and not that the > > initiator has opted not to use the unsolicited data feature. > > Therefore the > > spec needs to be modified to indicate that if unsolicited data has been > > negotiated (i.e. InitialR2T=no), then the initiator MUST send unsolicited > > data of length = min( FirstBurstSize, ExpectedTransferLength ) minus any > > immediate data sent). > > > > Matthew Burbridge > > NIS-Bristol > > Hewlett Packard > > Telnet: 312 7010 > > E-mail: matthewb@bri.hp.com > > > > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Tuesday, June 05, 2001 6:31 PM > > To: ips@ece.cmu.edu > > Subject: RE: Unsolicited Data. > > > > > > If the initiator decides not to send immediate or unsolicited data when it > > has negotiated to do so, then the initiator must set the F-bit in the > > command PDU. This prompts the target to send R2T. > > > > I still agree that the spec should indicate that the initiator > > MUST use the > > resources it has negotiated. If it has negotiated the option to send > > immediate data or unsolicited data then it should do that to the limits > > allowed. If it has negotiated a PDU length, it must not send data > > PDUs less > > than the negotiated limit except for last one. While most > > implementation may > > do that for performance reasons, I would prefer defining this in the spec. > > > > -Ayman > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > Sent: Tuesday, June 05, 2001 11:58 AM > > > To: 'ips@ece.cmu.edu' > > > Subject: Unsolicited Data. > > > > > > > > > I'm not sure if this has been discussed before but it is causing some > > > confusion. The statement below implies that if immediate data has been > > > negotiated then the initiator MAY use it. > > > > > > "If ImmediateData is set to no and InitialR2T is set to no then the > > > initiator MUST NOT send unsolicited immediate data but MAY send one > > > unsolicited burst of Data-OUT PDUs." > > > > > > Therefore the target must wait for the initial burst of unsolicited data > > > before issuing the first R2T (if there is subsequent data). If the > > > initiator decides not to send it then the target must timeout and > > > issue the > > > R2T for the initial data. Can the spec be changed to state that if > > > unsolicited data has been negotiated, then the initiator MUST use it. > > > > > > Thanks > > > > > > Matthew Burbridge > > > NIS-Bristol > > > Hewlett Packard > > > Telnet: 312 7010 > > > E-mail: matthewb@bri.hp.com > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 6 20:38:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11075 for ; Wed, 6 Jun 2001 20:38:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56N0n428089 for ips-outgoing; Wed, 6 Jun 2001 19:00:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56N0mg28085 for ; Wed, 6 Jun 2001 19:00:48 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA13016 for ; Wed, 6 Jun 2001 19:00:42 -0400 (EDT) Message-ID: <3B1EB593.E3F422F7@cisco.com> Date: Wed, 06 Jun 2001 17:58:27 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: More draft-06 comments References: <3B1D84E0.587199E3@agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Matt Wakeley wrote: > > julian_satran@il.ibm.com wrote: > > > ++++ although this text has no ambiguity there is still a raging debate > > between the proponents of an always explicit response (Matt and - in some > > covoluted form Steph - and those like Steve Senum who whould like a hiatus > > signaling a default. The current text let you set none by default. This > > can be changed by removing the " and MAY be selected by omission... " +++ > > I would like the "and MAY be selected by omission..." removed. If the "NotUnderstood" response exists, I would also like to see the option of not sending a response of key:none removed. Steve Senum From owner-ips@ece.cmu.edu Wed Jun 6 20:46:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11186 for ; Wed, 6 Jun 2001 20:46:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56MkoF27133 for ips-outgoing; Wed, 6 Jun 2001 18:46:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f56Mkmg27129 for ; Wed, 6 Jun 2001 18:46:48 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Wed Jun 6 18:43:35 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Wed Jun 6 18:46:33 EDT 2001 Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id SAA22069; Wed, 6 Jun 2001 18:46:20 -0400 (EDT) Message-ID: <3B1EB2BB.45A6E67E@research.bell-labs.com> Date: Wed, 06 Jun 2001 18:46:19 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ENDL_TX@computer.org CC: IPS Reflector Subject: Re: SAM-2 w/ multiple ports References: <3B181D2F.DF336D37@compuserve.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph Weber wrote: > > The SAM-2 revision with George's multiple ports > proposal incorporated is available at: > > ftp://ftp.t10.org/t10/drafts/sam2/sam2r18.pdf > > FYI > > Ralph... R Ralph, I had a couple of questions on Section 4.7.5 (SCSI Task Router) 1) "..Any task that is sent to a logical unit that is not known to the task router shall be routed to the default logical unit (e.g. LUN 0). This seems to conflict with the contents of Sec 5.8.3 (Incorrect LU selection). What is the rationale behind this statement ? 2) "Any task management function that is not sent to a specific logical unit shall be broadcast to all logical units known to the task router" Isnt this already covered under specific task functions anyways or is it intended to address some new functionality ? thanks -Sandeep P.S. Note that the T10 list has not been copied. From owner-ips@ece.cmu.edu Wed Jun 6 21:27:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11527 for ; Wed, 6 Jun 2001 21:27:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f56NXsW00140 for ips-outgoing; Wed, 6 Jun 2001 19:33:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f56LUPg22035 for ; Wed, 6 Jun 2001 17:30:25 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.177]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MG0NBSVD; Wed, 6 Jun 2001 17:30:19 -0400 Reply-To: From: "Eddy Quicksall" To: Subject: addendum Date: Wed, 6 Jun 2001 17:29:48 -0400 Message-ID: <001301c0eecf$d1a471b0$b101a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Is there an addendum or a list of EMAIL's that describe the changes going into REV 7? If not, what do you think about creating one. It could go on the http://www.ece.cmu.edu/~ips/Docs/docs.html page. mailto:Eddy@Quicksall.com From owner-ips@ece.cmu.edu Wed Jun 6 23:18:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14428 for ; Wed, 6 Jun 2001 23:18:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f571M9L06680 for ips-outgoing; Wed, 6 Jun 2001 21:22:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f571M7g06676 for ; Wed, 6 Jun 2001 21:22:07 -0400 (EDT) Received: from cs.uchicago.edu (h005018031eeb.ne.mediaone.net [24.91.84.19]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f571M1x24048 for ; Wed, 6 Jun 2001 21:22:01 -0400 (EDT) Message-Id: <200106070122.f571M1x24048@chmls05.mediaone.net> To: ips@ece.cmu.edu Subject: Re: Unsolicited Data. In-Reply-To: Message from "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" of "Thu, 07 Jun 2001 01:05:39 +0200." <003001c0eedd$34a67080$9600000a@daniel> References: <003001c0eedd$34a67080$9600000a@daniel> Date: Wed, 06 Jun 2001 21:19:48 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk Sanjeev, > why would initiator choose not to send unsolicited immediate data when > it has negotiated for IntialR2T= Yes?? I assume you mean InitialR2T=no. I would do this because I think that the real benefit of unsolicited data is for writes where ALL the write data can be sent unsolicited, and I'm happy to have the target schedule the transfer of (ALL) data for larger writes. Of course, others would say I'm a moron. Assuming the overwhelming majority of storage use is file access, small writes are exclusively file system metadata writes. Unsolicited data is a huge win for metadata writes because the latency of these metadata writes is frequently not covered by transferring other data (within a single access thread). On the other hand, the file system (usually) generates enough concurrent demand for real data writes that the flow control (R2T) latency is well hidden. You might argue that if you're running a file system optimized fors today's SANs over a link with a HUGE bandwidth * delay product (greater than the expected demand created by the file system), sending large amounts of unsolicited write data will substantially improve the link utilization. That is true, but I don't think many targets are going to offer unsolicited data bursts remotely that large. In a hardware accelerate implementation, unsolicited data will be handled differently than solicited data. The target can chose where the solicited data is delivered, but unsolicited data arrives through a general-delivery path. Therefore, if the offered unsolicited data burst size approaches the regular burst size, an implementation will need TWICE as much buffer memory (half in the general-delivery area and half in the flow-controlled buffer area) to support the same operation load. Maybe this tradeoff is OK, but given the cost sensitivity of storage targets, I doubt it. As always, I welcome comments from those who see things differently. Steph From owner-ips@ece.cmu.edu Thu Jun 7 01:29:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17093 for ; Thu, 7 Jun 2001 01:29:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f573UuB14498 for ips-outgoing; Wed, 6 Jun 2001 23:30:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f573Utg14493 for ; Wed, 6 Jun 2001 23:30:55 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id EA82A1081 for ; Wed, 6 Jun 2001 23:30:54 -0400 (EDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id UAA14037 for ips@ece.cmu.edu; Wed, 6 Jun 2001 20:32:03 -0700 (PDT) Message-Id: <200106070332.UAA14037@core.rose.hp.com> Subject: Re: iSCSI: Send Targets and Report Portal Groups To: ips@ece.cmu.edu Date: Wed, 06 Jun 2001 20:32:03 PDT In-Reply-To: ; from "John Hufferd" at Jun 6, 101 1:00 pm Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Some comments - - I think SendTargets is a useful functionality and should find place in the main draft. It is a discovery mechanism to find the multiple iSCSI targets behind one iSCSI address, just as the REPORT LUNS which finds the multiple LUs behind one SCSI target. Former is an iSCSI-ism with an iSCSI solution, the second is a SCSI-ism with a SCSI solution. - I fail to see why SendTargets should be placed in an annex, when it is not informative. I see this as no different from other areas like error recovery where we are hopeful of future simplifications, which we certainly are not placing in annexes today. - I agree with Paul that "Report Portal Groups" is nice but something that doesn't seem like a requirement, particularly if aggregation tags are supported by SendTargets. - I share the concern about feature creep in SendTargets. For example, the TargetAlias feature seems more like a management issue to me which I feel should be dropped. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >iSCSI Team, >I would like to propose the following approaches to address the issues of >Send-Targets, and Report Portal Groups. > >The way Send-Targets has evolved, which is now a separate interaction with >its own Login, makes it seem like the same function can be rationally >performed by current Discovery Functions in SLP or iSNS. Now this is not >completely correct, but close enough for me to propose a compromise. >Before I state the compromise let me address the items that are current >concerns with an SLP or iSNS approach of replacing Send-Targets. > >1. The current SLP Open Source does not do a Unicast to ask for the >information. This is not a shortcoming of the SLP protocol, just the >current API/Implementation. Mark Bakke has made a Hack into the Open >Source and believes that it will work just fine, and also thinks he has >support for that approach from the Owners of the Open Source. However, >there is still some uncertainty here, which will only be cleared up with >time and multiple implementations. >2. There are separate Authentication models followed by SLP/iSNS as opposed >to iSCSI. Therefore, any Initiator attempting to do SLP or iSNS for basic >discovery, needs to address two Authentication models, the discovery >method's authentication approach, and iSCSI's. >3. In small installations it is not clear that there will be an SLP or iSNS >setup on which to leverage this approach. > >Now, I am cretin there will be arguments about the importance of any of >those points, the issue is -- the uncertainty of favorable results. > >I am of the belief that it maybe worth the effort to move in the direction >of "atrophying" the Send Targets Command and Processes. That is, it serves >a current and valuable function, of which a favorable replacement, though >probable, is uncertain at this time. So we should begin moving in the >direction of the SLP/iSNS approach, but without additional care and feeding >of Send Targets. An approach to this is to move the Send Target Command >and Processes, into an Annex of the main iSCSI protocol document. As such >it will be a current requirement for implementation, but it will also be >clear that we believe it may be eliminated in version 2 of the iSCSI >document (when ever that occurs) and is not something in which feature >creep will be permitted. > >I think the above approach will satisfy the folks that have been building >and testing various product approaches that depend on Send Targets, and yet >give them time to move to an SLP or iSNS type approach as the concerns >specified above are worked out. > >It is also possible that in the future, we will find that we are >fundamentally wrong in some of our key assumptions, and that Version 2 may >move it back into the main document. That would also be acceptable, >because I do not believe it would happen lightly, and would have to have >great reasoning and logic behind such a move. > >Now, I would like to address the Report Portal Groups. I do not place this >in the same category as Send Targets. It is a specific query about the >environment of the specific session in which the command is issued. It is >analogous to Report LUNs, and querying Mode Pages. > >For those of you that have not been following this closely, the Report >Portal Groups, is a command that responds with the IP addresses that can be >used by the initiator of the current session, to add additional connections >to the current session (and thereby support Multiple Connections per >Session). > >It is specific to its own session, and not to some general management item. >Some might say that this too could be discovered by some management >function, however, that could also be true about many of the Mode Page >setting also. In my opinion the Portal Groups will probably be "wired in" >by the Storage Controller vendor and not be something that is settable by >the administrator. In fact with Report Portal Groups, being part of the >base protocol, the SLP/iSNS (or the Send Targets Command) will not have to >include the portal group identification/tagging in its responses, thus >simplifying them. > >So as part of my proposed compromise I recommend that we put "Report Portal >Groups" into the main iSCSI Protocol Document, like any of the other iSCSI >Commands, and move the Send-Targets command to an Annex as specified above. > > > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >(408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 >Internet address: hufferd@us.ibm.com > > From owner-ips@ece.cmu.edu Thu Jun 7 05:55:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02707 for ; Thu, 7 Jun 2001 05:55:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f577efi28549 for ips-outgoing; Thu, 7 Jun 2001 03:40:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f577eZg28532 for ; Thu, 7 Jun 2001 03:40:40 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 6D1D2141 for ; Thu, 7 Jun 2001 09:40:34 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id IAA29258 for ; Thu, 7 Jun 2001 08:40:33 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Thu, 07 Jun 2001 08:40:33 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 08:40:33 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A73E@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu Subject: RE: Unsolicited Data. Date: Thu, 7 Jun 2001 08:39:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Stephen, Sanjeev, and other interested parties, I whole heartily agree with both of your comments and see the benefit of unsolicited data in removing the R2T induced latency for both small writes and large writes on systems where such latency is an issue. However, for large writes the unsolicited portion of the data need not be all the data in the transfer but enough to overcome the initial latency. My main concern is that although the initiator and target have negoiated to use unsolicited data (InitialR2t=no), in the spec it appears to be optional. Therefore how does the target know that unsolicited data will be sent. Currently it does not and the target will have to set a timer that expires if no unsolicited data is forthcoming which will incur an even more unacceptable latency. I see that there are two options: 1)State in the spec that if unsolicited data has been negotiated then the initiator MUST honour it. (My preferred) 2)Have a flag in the SCSI Command PDU indicating that data is expected (No thanks). Thanks Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Stephen Bailey [mailto:steph@cs.uchicago.edu] Sent: Thursday, June 07, 2001 2:20 AM To: ips@ece.cmu.edu Subject: Re: Unsolicited Data. Sanjeev, > why would initiator choose not to send unsolicited immediate data when > it has negotiated for IntialR2T= Yes?? I assume you mean InitialR2T=no. I would do this because I think that the real benefit of unsolicited data is for writes where ALL the write data can be sent unsolicited, and I'm happy to have the target schedule the transfer of (ALL) data for larger writes. Of course, others would say I'm a moron. Assuming the overwhelming majority of storage use is file access, small writes are exclusively file system metadata writes. Unsolicited data is a huge win for metadata writes because the latency of these metadata writes is frequently not covered by transferring other data (within a single access thread). On the other hand, the file system (usually) generates enough concurrent demand for real data writes that the flow control (R2T) latency is well hidden. You might argue that if you're running a file system optimized fors today's SANs over a link with a HUGE bandwidth * delay product (greater than the expected demand created by the file system), sending large amounts of unsolicited write data will substantially improve the link utilization. That is true, but I don't think many targets are going to offer unsolicited data bursts remotely that large. In a hardware accelerate implementation, unsolicited data will be handled differently than solicited data. The target can chose where the solicited data is delivered, but unsolicited data arrives through a general-delivery path. Therefore, if the offered unsolicited data burst size approaches the regular burst size, an implementation will need TWICE as much buffer memory (half in the general-delivery area and half in the flow-controlled buffer area) to support the same operation load. Maybe this tradeoff is OK, but given the cost sensitivity of storage targets, I doubt it. As always, I welcome comments from those who see things differently. Steph From owner-ips@ece.cmu.edu Thu Jun 7 10:25:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07937 for ; Thu, 7 Jun 2001 10:25:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57CXkA25176 for ips-outgoing; Thu, 7 Jun 2001 08:33:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57CXdg25170 for ; Thu, 7 Jun 2001 08:33:39 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 754311CD for ; Thu, 7 Jun 2001 14:33:37 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id NAA12812 for ; Thu, 7 Jun 2001 13:33:37 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Thu, 07 Jun 2001 13:33:36 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 13:33:36 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A741@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu Subject: RE: Unsolicited Data. Date: Thu, 7 Jun 2001 13:33:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Sanjeev, Perhaps I'm getting confused here: From 2.3.1 below, if the F bit is set then it indicates the immediate data that acompany the command is all the data associated with the command. However, if there is no immediated data, but data is to be written the F bit can not be set to 1. In this case the data is either sent a unsolicited Data PDUs or as solicited data PDUs. This reverts back to my original point of changing the spec to state that if unsolicited data has been negoiated then the initiator MUST honour it. With regards to your comment: "Is it still going to help if Unsolicited data is not chosen to be sent while IntialR2t=No has been negotiated???? Or do I have misunderstanding with a general delivery path here." may I can explain my concern: If the initiator does not choose to send unsolicited data although it has negoiated to do so, how is the data transfers insigated as the target is expecting unsoliciated Data PDU but the initiator is expecting an R2T? Feel free to call me so we can discuss offline. Thanks Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 Tel UK (44) 117 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] Sent: Thursday, June 07, 2001 1:09 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'; ips@ece.cmu.edu Cc: 'steph@cs.uchicago.edu' Subject: RE: Unsolicited Data. Matthew, among the two options you gave I would like to comment on the second It is possible for initiator **not** to send any unsolicited data and send the rest of data as solicited data by the use of bit 7 in Flags and Task Attributes. This is posted here http://ips.pdl.cs.cmu.edu/mail/msg04647.html The new 2.3.1 is: 2.3.1 Flags and Task Attributes The flags for a SCSI Command are: b7 (F) set to 1 when the immediate data that accompany the command are all the unsolicited data associated with this command. For a write, if Expected Data Transfer Length is larger than the Length the target may solicit additional data through R2T. About the option no. 1 Stephen has already explained. Refer to the very specific paragraph below of his email In a hardware accelerate implementation, unsolicited data will be handled differently than solicited data. The target can chose where the solicited data is delivered, but unsolicited data arrives through a general-delivery path. Therefore, if the offered unsolicited data burst size approaches the regular burst size, an implementation will need TWICE as much buffer memory (half in the general-delivery area and half in the flow-controlled buffer area) to support the same operation load. Maybe this tradeoff is OK, but given the cost sensitivity of storage targets, I doubt it. I would like to comment one thing here that in the current iSCSI specs implementation the complete data for a specific command Including (Cmd PDUS , Data PDUs and Response PDUs) follow the same path. So the whole of data will follow the general delivery path (same connection) whether solicited or unsolicited. Is it still going to help if Unsolicited data is not chosen to be sent while IntialR2t=No has been negotiated???? Or do I have misunderstanding with a general delivery path here. Regards, Sanjeev -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, June 07, 2001 12:40 AM To: ips@ece.cmu.edu Subject: RE: Unsolicited Data. Hi Stephen, Sanjeev, and other interested parties, I whole heartily agree with both of your comments and see the benefit of unsolicited data in removing the R2T induced latency for both small writes and large writes on systems where such latency is an issue. However, for large writes the unsolicited portion of the data need not be all the data in the transfer but enough to overcome the initial latency. My main concern is that although the initiator and target have negoiated to use unsolicited data (InitialR2t=no), in the spec it appears to be optional. Therefore how does the target know that unsolicited data will be sent. Currently it does not and the target will have to set a timer that expires if no unsolicited data is forthcoming which will incur an even more unacceptable latency. I see that there are two options: 1)State in the spec that if unsolicited data has been negotiated then the initiator MUST honour it. (My preferred) 2)Have a flag in the SCSI Command PDU indicating that data is expected (No thanks). Thanks Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Stephen Bailey [mailto:steph@cs.uchicago.edu] Sent: Thursday, June 07, 2001 2:20 AM To: ips@ece.cmu.edu Subject: Re: Unsolicited Data. Sanjeev, > why would initiator choose not to send unsolicited immediate data when > it has negotiated for IntialR2T= Yes?? I assume you mean InitialR2T=no. I would do this because I think that the real benefit of unsolicited data is for writes where ALL the write data can be sent unsolicited, and I'm happy to have the target schedule the transfer of (ALL) data for larger writes. Of course, others would say I'm a moron. Assuming the overwhelming majority of storage use is file access, small writes are exclusively file system metadata writes. Unsolicited data is a huge win for metadata writes because the latency of these metadata writes is frequently not covered by transferring other data (within a single access thread). On the other hand, the file system (usually) generates enough concurrent demand for real data writes that the flow control (R2T) latency is well hidden. You might argue that if you're running a file system optimized fors today's SANs over a link with a HUGE bandwidth * delay product (greater than the expected demand created by the file system), sending large amounts of unsolicited write data will substantially improve the link utilization. That is true, but I don't think many targets are going to offer unsolicited data bursts remotely that large. In a hardware accelerate implementation, unsolicited data will be handled differently than solicited data. The target can chose where the solicited data is delivered, but unsolicited data arrives through a general-delivery path. Therefore, if the offered unsolicited data burst size approaches the regular burst size, an implementation will need TWICE as much buffer memory (half in the general-delivery area and half in the flow-controlled buffer area) to support the same operation load. Maybe this tradeoff is OK, but given the cost sensitivity of storage targets, I doubt it. As always, I welcome comments from those who see things differently. Steph From owner-ips@ece.cmu.edu Thu Jun 7 10:25:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07935 for ; Thu, 7 Jun 2001 10:25:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57CBX723740 for ips-outgoing; Thu, 7 Jun 2001 08:11:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com ([217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57CBVg23735 for ; Thu, 7 Jun 2001 08:11:32 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 14:08:49 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B968C@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'" , ips@ece.cmu.edu Cc: "'steph@cs.uchicago.edu'" Subject: RE: Unsolicited Data. Date: Thu, 7 Jun 2001 14:08:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Matthew, among the two options you gave I would like to comment on the second It is possible for initiator **not** to send any unsolicited data and send the rest of data as solicited data by the use of bit 7 in Flags and Task Attributes. This is posted here http://ips.pdl.cs.cmu.edu/mail/msg04647.html The new 2.3.1 is: 2.3.1 Flags and Task Attributes The flags for a SCSI Command are: b7 (F) set to 1 when the immediate data that accompany the command are all the unsolicited data associated with this command. For a write, if Expected Data Transfer Length is larger than the Length the target may solicit additional data through R2T. About the option no. 1 Stephen has already explained. Refer to the very specific paragraph below of his email In a hardware accelerate implementation, unsolicited data will be handled differently than solicited data. The target can chose where the solicited data is delivered, but unsolicited data arrives through a general-delivery path. Therefore, if the offered unsolicited data burst size approaches the regular burst size, an implementation will need TWICE as much buffer memory (half in the general-delivery area and half in the flow-controlled buffer area) to support the same operation load. Maybe this tradeoff is OK, but given the cost sensitivity of storage targets, I doubt it. I would like to comment one thing here that in the current iSCSI specs implementation the complete data for a specific command Including (Cmd PDUS , Data PDUs and Response PDUs) follow the same path. So the whole of data will follow the general delivery path (same connection) whether solicited or unsolicited. Is it still going to help if Unsolicited data is not chosen to be sent while IntialR2t=No has been negotiated???? Or do I have misunderstanding with a general delivery path here. Regards, Sanjeev -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, June 07, 2001 12:40 AM To: ips@ece.cmu.edu Subject: RE: Unsolicited Data. Hi Stephen, Sanjeev, and other interested parties, I whole heartily agree with both of your comments and see the benefit of unsolicited data in removing the R2T induced latency for both small writes and large writes on systems where such latency is an issue. However, for large writes the unsolicited portion of the data need not be all the data in the transfer but enough to overcome the initial latency. My main concern is that although the initiator and target have negoiated to use unsolicited data (InitialR2t=no), in the spec it appears to be optional. Therefore how does the target know that unsolicited data will be sent. Currently it does not and the target will have to set a timer that expires if no unsolicited data is forthcoming which will incur an even more unacceptable latency. I see that there are two options: 1)State in the spec that if unsolicited data has been negotiated then the initiator MUST honour it. (My preferred) 2)Have a flag in the SCSI Command PDU indicating that data is expected (No thanks). Thanks Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Stephen Bailey [mailto:steph@cs.uchicago.edu] Sent: Thursday, June 07, 2001 2:20 AM To: ips@ece.cmu.edu Subject: Re: Unsolicited Data. Sanjeev, > why would initiator choose not to send unsolicited immediate data when > it has negotiated for IntialR2T= Yes?? I assume you mean InitialR2T=no. I would do this because I think that the real benefit of unsolicited data is for writes where ALL the write data can be sent unsolicited, and I'm happy to have the target schedule the transfer of (ALL) data for larger writes. Of course, others would say I'm a moron. Assuming the overwhelming majority of storage use is file access, small writes are exclusively file system metadata writes. Unsolicited data is a huge win for metadata writes because the latency of these metadata writes is frequently not covered by transferring other data (within a single access thread). On the other hand, the file system (usually) generates enough concurrent demand for real data writes that the flow control (R2T) latency is well hidden. You might argue that if you're running a file system optimized fors today's SANs over a link with a HUGE bandwidth * delay product (greater than the expected demand created by the file system), sending large amounts of unsolicited write data will substantially improve the link utilization. That is true, but I don't think many targets are going to offer unsolicited data bursts remotely that large. In a hardware accelerate implementation, unsolicited data will be handled differently than solicited data. The target can chose where the solicited data is delivered, but unsolicited data arrives through a general-delivery path. Therefore, if the offered unsolicited data burst size approaches the regular burst size, an implementation will need TWICE as much buffer memory (half in the general-delivery area and half in the flow-controlled buffer area) to support the same operation load. Maybe this tradeoff is OK, but given the cost sensitivity of storage targets, I doubt it. As always, I welcome comments from those who see things differently. Steph From owner-ips@ece.cmu.edu Thu Jun 7 13:40:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11298 for ; Thu, 7 Jun 2001 13:40:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57EpYN04985 for ips-outgoing; Thu, 7 Jun 2001 10:51:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57EpWg04981 for ; Thu, 7 Jun 2001 10:51:32 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA10399; Thu, 7 Jun 2001 10:51:20 -0400 (EDT) Message-ID: <3B1F9411.2F6FE378@cisco.com> Date: Thu, 07 Jun 2001 09:47:45 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Venkat Rangan CC: "'julian_satran@il.ibm.com'" , ips@ece.cmu.edu Subject: Re: iSCSI: Nailing down CRC-32C References: <45BEF1D68145D51186C100B0D0AABE6503D3ED@med.corp.rhapsodynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Venkat- Sorry for the high-latency response; it took a while to get back to this thread. Anyway, I don't see any particular reason why the bit ordering has to be one way or the other, except that it will be easier for everyone if we do the reflection both in and out, since it will match what is done on Ethernet, Fibre Channel, and ultra-SCSI. Looking at these documents, I think that the simplest and least ambiguous description of the CRC is in the T10 SPI-3 (rev 14, page 121). It includes a description of the bit ordering, as well as a few simple test cases. It's at: ftp://ftp.t10.org/t10/drafts/spi3/spi3r14.pdf Julian, I think that the last data integrity section you had sent covers everything except the bit ordering. If we copied the statement: Bytes are bit reversed prior to generating the remainder and the bytes of the remainder are bit reversed prior to forming the CRC field. from the T10 doc, I think that everything else is specified. It would then be helpful as a check to include a few test cases that people could run. I took the T10 test cases, and ran them through with (my interpretation of) the iSCSI CRC-32C: For a 32-byte transfer of all 00h, the CRC will be 8A9136AA (the most significant byte would be the first byte transmitted on the network interface). For a 32-byte transfer of all FFh, the CRC will be 62A8AB43. For a 32-byte incrementing test pattern of bytes starting with 00h and ending with 1Fh, in network order, the CRC will be 46DD794E. This should be sufficient for someone to test their hardware or software implementation of the iSCSI CRC, and ensure that it will be interoperable. If desired, we could also make up a sample iSCSI header (perhaps an inquiry command or something equally common), along with its expected CRC. Can we add the above statements on bit ordering and test cases to the draft-07? It will give us the best possible chance of everyone's implementation of the CRC to match the first time. -- Mark Venkat Rangan wrote: > > Mark, > > Is there any specific advantage to iSCSI Reflection Parameters > to be different from that of Ethernet? Does CRC32-C benefit by > a different set of parameters? If so, what are they, and how do we > get closure on a particular set of parameters? > > Purely from the description of the parameters, RefIn=TRUE means that each > byte from the stream is 'reflected' so that bit 0 is fed in first and > then bit 1 etc. RefOut=TRUE means that the 32-bit value of the CRC is also > reflected before the final XOR is done. > > Currently, Ethernet has 'RefIn=TRUE' and 'RefOut= TRUE'. > > Thanks, > > Venkat Rangan > Rhapsody Networks Inc. > http://www.rhapsodynetworks.com > > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Tuesday, May 15, 2001 5:16 AM > To: Venkat Rangan > Cc: 'julian_satran@il.ibm.com'; ips@ece.cmu.edu > Subject: Re: iSCSI: Nailing down CRC-32C > > Venkat- > > I assumed the same parameters (iSCSI has not yet specified > the reflection parameters), and obtained the same check you > did with their code. > > -- > Mark > > Venkat Rangan wrote: > > > > All, > > > > Based on the finalization of the parameters of CRC-32C per following > > parameters, I obtained a check of 0xE3069283 for the nine-byte string of > > "123456789" (9 bytes) that the Rocksoft CRC document refers to. > > > > Name : "CRC-32C" > > Width : 32 > > Poly : 1EDC6F41 (note that the leading "1" is implied) > > Init : FFFFFFFF > > RefIn : True > > RefOut : True > > XorOut : FFFFFFFF > > Check : E3069283 > > > > It would be nice if other independant checks can validate this. > > > > Venkat Rangan > > Rhapsody Networks Inc. > > http://www.rhapsodynetworks.com > > > > The table and code follows: > > > > /*****************************************************************/ > > /* */ > > /* CRC LOOKUP TABLE */ > > /* ================ */ > > /* The following CRC lookup table was generated automagically */ > > /* by the Rocksoft^tm Model CRC Algorithm Table Generation */ > > /* Program V1.0 using the following model parameters: */ > > /* */ > > /* Width : 4 bytes. */ > > /* Poly : 0x1EDC6F41L */ > > /* Reverse : TRUE. */ > > /* */ > > /* For more information on the Rocksoft^tm Model CRC Algorithm, */ > > /* see the document titled "A Painless Guide to CRC Error */ > > /* Detection Algorithms" by Ross Williams */ > > /* (ross@guest.adelaide.edu.au.). This document is likely to be */ > > /* in the FTP archive "ftp.adelaide.edu.au/pub/rocksoft". */ > > /* */ > > /*****************************************************************/ > > > > unsigned long crctable[256] = > > { > > 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, > > 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, > > 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, > > 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, > > 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, > > 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, > > 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, > > 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, > > 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, > > 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, > > 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, > > 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, > > 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, > > 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, > > 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, > > 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, > > 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, > > 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, > > 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, > > 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, > > 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, > > 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, > > 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, > > 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, > > 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, > > 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, > > 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, > > 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, > > 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, > > 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, > > 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, > > 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, > > 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, > > 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, > > 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, > > 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, > > 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, > > 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, > > 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, > > 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, > > 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, > > 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, > > 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, > > 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, > > 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, > > 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, > > 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, > > 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, > > 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, > > 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, > > 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, > > 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, > > 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, > > 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, > > 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, > > 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, > > 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, > > 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, > > 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, > > 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, > > 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, > > 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, > > 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, > > 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L > > }; > > > > /*****************************************************************/ > > /* End of CRC Lookup Table */ > > /*****************************************************************/ > > > > /*****************************************************************/ > > /* ComputeCRC */ > > /*****************************************************************/ > > #include > > #include > > #include "crctable.h" > > > > #define TB_INIT 0xFFFFFFFF > > #define TB_INIT_REFLECTED 0xFFFFFFFF > > #define TB_XOROT 0xFFFFFFFF > > > > unsigned long crc_reflected (); > > unsigned long crc_reflected (blk_adr,blk_len) > > unsigned char *blk_adr; > > unsigned long blk_len; > > { > > unsigned long crc = TB_INIT_REFLECTED; > > while (blk_len--) > > crc = crctable[(crc ^ *blk_adr++) & 0xFFL] ^ (crc >> 8); > > return crc ^ TB_XOROT; > > } > > > > -----Original Message----- > > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] > > Sent: Tuesday, May 08, 2001 7:38 AM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI: Nailing down CRC-32C > > > > Mark, > > > > My basic assumption was that everything is (as in all IP related > standards) > > in network order. > > > > Regards, > > Julo > > > > Mark Bakke on 07-05-2001 23:00:28 > > > > Please respond to Mark Bakke > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: Nailing down CRC-32C > > > > Julian- > > > > That's great; it covers nearly everything. The only thing left > > is the byte order; are they taken in the same order Ethernet uses? > > > > If so, I can generate a few test patterns that our implementations > > can all check against. > > > > Thanks, > > > > -- > > Mark > > > > julian_satran@il.ibm.com wrote: > > > > > > The CRC part of the appendix (for 07) reads: > > > > > > The following table lists cyclic integrity checksums that can be > > > negotiated for the digests and MUST be implemented by every iSCSI > > > initiator and target. Note that these digest options have only error > > > detection significance. > > > > > > +---------------------------------------------+ > > > | Name | Description | > > > +---------------------------------------------+ > > > | crc-32C | 32 bit CRC | 11EDC6F41 | > > > +---------------------------------------------+ > > > | none | no digest | > > > +---------------------------------------------+ > > > > > > The generator polynomials for those digests are given in > hex-notation, > > > for example 3a stands for 0011 1010 - the polynomial > > x**5+X**4+x**3+x+1. > > > > > > The generator polynomial selected is evaluated in [Castagnioli93]. > > > When using the CRC the CRC register must be initialized to all 1s > > > (0xFFFFFFFF) and the CRC bits must be complemented before > > transmission. > > > Padding bytes, when presents in a segment covered by a CRC, have to > be > > > set to 0 and are included in the CRC. > > > > > > Regards, > > > Julo > > > > > > Mark Bakke on 05-05-2001 00:13:09 > > > > > > Please respond to Mark Bakke > > > > > > To: IPS > > > cc: > > > Subject: iSCSI: Nailing down CRC-32C > > > > > > At the interim meeting, it was stated that iSCSI has selected > > > the CRC-32C polynomial as its required iSCSI-level header and > > > data CRC. Now that we have it, it's time to move on and make > > > sure we can implement it. > > > > > > In the interest of interoperability, we need to not only specify > > > the polynomial, but also the initial values, bit and byte > > > ordering, etc. > > > > > > "A Painless Guide to CRC Error Detection Algorithms" > > > (http://www.ross.net/crc/crcpaper.html) specifies a > > > method to unambiguously characterize these parameters > > > (sections 15 and 16). Has anyone taken a shot at defining > > > these yet? Otherwise, here is what it might look like: > > > > > > Name : "CRC-32C" > > > Width : 32 > > > Poly : 1EDC6F41 (note that the leading "1" is implied) > > > Init : FFFFFFFF > > > RefIn : True > > > RefOut : True > > > XorOut : FFFFFFFF > > > Check : ? > > > > > > I haven't attempted to create check data based on these yet. As > > > soon as the other parameters are nailed down, we need to do this. > > > > > > Anyway, I am not a CRC expert, and can't make any statement about > > > the above values being the "best" way to do this, but instead just > > > copied them (except the polynomial itself) from the Ethernet CRC, > > > since that is likely the easiest for everyone implementing hardware > > > to deal with. > > > > > > If someone else is already doing this, let me know; I just wanted > > > to start this thread so we can get closure. > > > > > > Regards, > > > > > > Mark > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jun 7 16:14:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13763 for ; Thu, 7 Jun 2001 16:14:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57I3rG19921 for ips-outgoing; Thu, 7 Jun 2001 14:03:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57I3qg19917 for ; Thu, 7 Jun 2001 14:03:52 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id 0D8C61F1E; Thu, 7 Jun 2001 11:03:51 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id LAA16712; Thu, 7 Jun 2001 11:05:00 -0700 (PDT) Message-Id: <200106071805.LAA16712@core.rose.hp.com> Subject: Re: Unsolicited Data. To: steph@cs.uchicago.edu Date: Thu, 07 Jun 2001 11:04:59 PDT Cc: ips@ece.cmu.edu In-Reply-To: <200106070122.f571M1x24048@chmls05.mediaone.net>; from "Stephen Bailey" at Jun 6, 101 7:30 pm Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Steph, I agree with you that mandating unsolicited data to be sent always is limiting, even if InitialR2T=no is negotiated. I suggest the following for consideration - - If the command F-bit is set: - if immediate data is present, it's all the data for the command. (as in rev06) - if immediate data is not present, there are no unsolicited data PDUs following. - If the command F-bit is not set: - if immediate is present, there is more solicited data to follow. - if immediate data is not present, there may be solicited data depending on "Expected Data Transfer Length". The only case this disallows is that of having _both_ unsolicited separate PDUs and immediate data for a command - which I personally am okay with. This is disallowed in rev06 anyway, but for some reason seemed like was changed later. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com > >Sanjeev, > >> why would initiator choose not to send unsolicited immediate data when >> it has negotiated for IntialR2T= Yes?? > >I assume you mean InitialR2T=no. > >I would do this because I think that the real benefit of unsolicited >data is for writes where ALL the write data can be sent unsolicited, >and I'm happy to have the target schedule the transfer of (ALL) data >for larger writes. Of course, others would say I'm a moron. > >Assuming the overwhelming majority of storage use is file access, >small writes are exclusively file system metadata writes. Unsolicited >data is a huge win for metadata writes because the latency of these >metadata writes is frequently not covered by transferring other data >(within a single access thread). On the other hand, the file system >(usually) generates enough concurrent demand for real data writes that >the flow control (R2T) latency is well hidden. > >You might argue that if you're running a file system optimized fors >today's SANs over a link with a HUGE bandwidth * delay product >(greater than the expected demand created by the file system), sending >large amounts of unsolicited write data will substantially improve the >link utilization. That is true, but I don't think many targets are >going to offer unsolicited data bursts remotely that large. > >In a hardware accelerate implementation, unsolicited data will be >handled differently than solicited data. The target can chose where >the solicited data is delivered, but unsolicited data arrives through >a general-delivery path. Therefore, if the offered unsolicited data >burst size approaches the regular burst size, an implementation will >need TWICE as much buffer memory (half in the general-delivery area >and half in the flow-controlled buffer area) to support the same >operation load. Maybe this tradeoff is OK, but given the cost >sensitivity of storage targets, I doubt it. > >As always, I welcome comments from those who see things differently. > >Steph > From owner-ips@ece.cmu.edu Thu Jun 7 16:17:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13819 for ; Thu, 7 Jun 2001 16:17:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57Ih8q23018 for ips-outgoing; Thu, 7 Jun 2001 14:43:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57Ih6g23010 for ; Thu, 7 Jun 2001 14:43:06 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel1.hp.com (Postfix) with ESMTP id A2111F52 for ; Thu, 7 Jun 2001 11:43:01 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id LAA26893 for ips@ece.cmu.edu; Thu, 7 Jun 2001 11:44:10 -0700 (PDT) Message-Id: <200106071844.LAA26893@core.rose.hp.com> Subject: iSCSI: statement on mandatory/optional To: ips@ece.cmu.edu Date: Thu, 07 Jun 2001 11:44:10 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I suggest the following explanatory text to be added to the iSCSI main draft (possibly as section 1.2.1). I really think this (in an abstract sense) helps readers to understand the optionality or otherwise of iSCSI features. Mandatory and optional features - All the features that are specified in this draft are mandatory to implement and mandatory to use, unless otherwise stated. - Features that are identified as "mandatory to implement but optional to use" (like the digests) MUST be implemented and MUST be honored by one side when the other side uses them (as in a PDU type), or wants to use them (as in negotiation). - Features that are identified as "optional to implement" (like the synch and steering layer) imply that implementations that support the features MUST interoperate with other implementations that do not support these features (i.e. implementations are guaranteed to be interoperable regardless of the feature support). Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Thu Jun 7 16:34:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14074 for ; Thu, 7 Jun 2001 16:34:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57JA8w25075 for ips-outgoing; Thu, 7 Jun 2001 15:10:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57JA5g25062 for ; Thu, 7 Jun 2001 15:10:05 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id PAA20530 for ips@ece.cmu.edu; Thu, 7 Jun 2001 15:10:00 -0400 (EDT) Received: from compuserve.com (chi-tgn-goo-vty33.as.wcom.net [216.192.136.33]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id PAA20522; Thu, 7 Jun 2001 15:09:57 -0400 (EDT) Message-ID: <3B1F5B7F.E60D7896@compuserve.com> Date: Thu, 07 Jun 2001 05:46:23 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector CC: Sandeep Joshi , George Penokie Subject: Re: SAM-2 w/ multiple ports References: <3B181D2F.DF336D37@compuserve.com> <3B1EB2BB.45A6E67E@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sandeep, The responses to your questions about the SAM-2 multi-port model are as follows: > 1) "..Any task that is sent to a logical unit that is not known > to the task router shall be routed to the default logical > unit (e.g. LUN 0). > > This seems to conflict with the contents of Sec 5.8.3 (Incorrect > LU selection). What is the rationale behind this statement ? The Task Router cannot form the response to incorrect logical unit selection that is described in 5.8.3. Therefore, the Task Router is obliged to route the task to the default logical unit, who can form the response. > 2) "Any task management function that is > not sent to a specific logical unit shall be broadcast to > all logical units known to the task router" > > Isnt this already covered under specific task functions anyways > or is it intended to address some new functionality ? The mechanism described is present to provide the routing necessary to effect the requirements stated in the specific task management function descriptions. In summary, the routing requirements in question are present to make the Task Router an operative participant in existing SCSI model requirements, not to instantiate new requirements. Thanks. Ralph... From owner-ips@ece.cmu.edu Thu Jun 7 17:19:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14768 for ; Thu, 7 Jun 2001 17:19:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57JlFp28097 for ips-outgoing; Thu, 7 Jun 2001 15:47:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57JlDg28086 for ; Thu, 7 Jun 2001 15:47:13 -0400 (EDT) Received: from HQMailWeb.Crossroads.com [63.237.99.250:25] by va2mc.ummailbox.net with SMTP id F0607-1546-60c900; Thu, 7 Jun 2001 19:46:16 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 7 Jun 2001 14:46:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: iSCSI: statement on mandatory/optional Date: Thu, 7 Jun 2001 14:46:15 -0500 Message-ID: Thread-Topic: iSCSI: statement on mandatory/optional Thread-Index: AcDvh6DmmtDSsYHXRMaxDjI+J8/NAwAAnZbQ From: "Robert Griswold" To: , X-OriginalArrivalTime: 07 Jun 2001 19:46:16.0021 (UTC) FILETIME=[83AF6850:01C0EF8A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f57JlDg28087 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Mallikarjun: I agree with your suggestion in concept, leaving it to those with the IETF experience to draw up the words, if yours don't work. Given the cross-over technology that this represents for engineers used to one style of standards wording, this kind of a paragraph would help with the interpretation issues. Good suggestion. Bob Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Thursday, June 07, 2001 1:44 PM To: ips@ece.cmu.edu Subject: iSCSI: statement on mandatory/optional Julian, I suggest the following explanatory text to be added to the iSCSI main draft (possibly as section 1.2.1). I really think this (in an abstract sense) helps readers to understand the optionality or otherwise of iSCSI features. Mandatory and optional features - All the features that are specified in this draft are mandatory to implement and mandatory to use, unless otherwise stated. - Features that are identified as "mandatory to implement but optional to use" (like the digests) MUST be implemented and MUST be honored by one side when the other side uses them (as in a PDU type), or wants to use them (as in negotiation). - Features that are identified as "optional to implement" (like the synch and steering layer) imply that implementations that support the features MUST interoperate with other implementations that do not support these features (i.e. implementations are guaranteed to be interoperable regardless of the feature support). Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Thu Jun 7 17:19:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14779 for ; Thu, 7 Jun 2001 17:19:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57JQDv26361 for ips-outgoing; Thu, 7 Jun 2001 15:26:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe68.law11.hotmail.com [64.4.16.203]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57JQBg26356 for ; Thu, 7 Jun 2001 15:26:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 7 Jun 2001 12:26:05 -0700 X-Originating-IP: [216.135.246.226] From: "Eddy Quicksall" To: "BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)" , References: <0B9A57FF1D57D411B47500D0B73E5CC101E7A741@dickens.bri.hp.com> Subject: Re: Unsolicited Data. Date: Thu, 7 Jun 2001 15:25:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 07 Jun 2001 19:26:05.0922 (UTC) FILETIME=[B268F420:01C0EF87] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It says "all the unsolicited data associated ". You read it as "all the data associated". Does that help the confusion? Eddy ----- Original Message ----- From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: Sent: Thursday, June 07, 2001 8:33 AM Subject: RE: Unsolicited Data. > Hi Sanjeev, > > Perhaps I'm getting confused here: From 2.3.1 below, if the F bit is set > then it indicates the immediate data that acompany the command is all the > data associated with the command. However, if there is no immediated data, > but data is to be written the F bit can not be set to 1. In this case the > data is either sent a unsolicited Data PDUs or as solicited data PDUs. This > reverts back to my original point of changing the spec to state that if > unsolicited data has been negoiated then the initiator MUST honour it. > > With regards to your comment: "Is it still going to help if Unsolicited data > is not chosen to be sent while IntialR2t=No has been negotiated???? Or do I > have misunderstanding with a general delivery path here." may I can explain > my concern: If the initiator does not choose to send unsolicited data > although it has negoiated to do so, how is the data transfers insigated as > the target is expecting unsoliciated Data PDU but the initiator is expecting > an R2T? > > Feel free to call me so we can discuss offline. > > Thanks > > Matthew Burbridge > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > Tel UK (44) 117 312 7010 > E-mail: matthewb@bri.hp.com > > > > -----Original Message----- > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] > Sent: Thursday, June 07, 2001 1:09 PM > To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'; ips@ece.cmu.edu > Cc: 'steph@cs.uchicago.edu' > Subject: RE: Unsolicited Data. > > > Matthew, > > among the two options you gave I would like to comment on the second > > It is possible for initiator **not** to send any unsolicited data and send > the rest of data as solicited data by the use of bit 7 in Flags and Task > Attributes. This is posted here http://ips.pdl.cs.cmu.edu/mail/msg04647.html > > The new 2.3.1 is: > > 2.3.1 Flags and Task Attributes > > The flags for a SCSI Command are: > > b7 (F) set to 1 when the immediate data that accompany the command > are all the unsolicited data associated with this command. For a > write, if Expected Data Transfer Length is larger than the Length the > target may solicit additional data through R2T. > > About the option no. 1 Stephen has already explained. Refer to the very > specific paragraph below of his email > > In a hardware accelerate implementation, unsolicited data will be > handled differently than solicited data. The target can chose where > the solicited data is delivered, but unsolicited data arrives through > a general-delivery path. Therefore, if the offered unsolicited data > burst size approaches the regular burst size, an implementation will > need TWICE as much buffer memory (half in the general-delivery area > and half in the flow-controlled buffer area) to support the same > operation load. Maybe this tradeoff is OK, but given the cost > sensitivity of storage targets, I doubt it. > > I would like to comment one thing here that in the current iSCSI specs > implementation the complete data for a specific command Including (Cmd PDUS > , Data PDUs and Response PDUs) follow the same path. So the whole of data > will follow the general delivery path (same connection) whether solicited or > unsolicited. Is it still going to help if Unsolicited data is not chosen to > be sent while IntialR2t=No has been negotiated???? Or do I have > misunderstanding with a general delivery path here. > > Regards, > Sanjeev > > -----Original Message----- > From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > [mailto:matthew_burbridge@hp.com] > Sent: Thursday, June 07, 2001 12:40 AM > To: ips@ece.cmu.edu > Subject: RE: Unsolicited Data. > > > Hi Stephen, Sanjeev, and other interested parties, > > I whole heartily agree with both of your comments and see the benefit of > unsolicited data in removing the R2T induced latency for both small writes > and large writes on systems where such latency is an issue. However, for > large writes the unsolicited portion of the data need not be all the data in > the transfer but enough to overcome the initial latency. > > My main concern is that although the initiator and target have negoiated to > use unsolicited data (InitialR2t=no), in the spec it appears to be optional. > Therefore how does the target know that unsolicited data will be sent. > Currently it does not and the target will have to set a timer that expires > if no unsolicited data is forthcoming which will incur an even more > unacceptable latency. > > I see that there are two options: > 1)State in the spec that if unsolicited data has been negotiated then the > initiator MUST honour it. (My preferred) > 2)Have a flag in the SCSI Command PDU indicating that data is expected (No > thanks). > > Thanks > > Matthew Burbridge > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > > -----Original Message----- > From: Stephen Bailey [mailto:steph@cs.uchicago.edu] > Sent: Thursday, June 07, 2001 2:20 AM > To: ips@ece.cmu.edu > Subject: Re: Unsolicited Data. > > > Sanjeev, > > > why would initiator choose not to send unsolicited immediate data when > > it has negotiated for IntialR2T= Yes?? > > I assume you mean InitialR2T=no. > > I would do this because I think that the real benefit of unsolicited > data is for writes where ALL the write data can be sent unsolicited, > and I'm happy to have the target schedule the transfer of (ALL) data > for larger writes. Of course, others would say I'm a moron. > > Assuming the overwhelming majority of storage use is file access, > small writes are exclusively file system metadata writes. Unsolicited > data is a huge win for metadata writes because the latency of these > metadata writes is frequently not covered by transferring other data > (within a single access thread). On the other hand, the file system > (usually) generates enough concurrent demand for real data writes that > the flow control (R2T) latency is well hidden. > > You might argue that if you're running a file system optimized fors > today's SANs over a link with a HUGE bandwidth * delay product > (greater than the expected demand created by the file system), sending > large amounts of unsolicited write data will substantially improve the > link utilization. That is true, but I don't think many targets are > going to offer unsolicited data bursts remotely that large. > > In a hardware accelerate implementation, unsolicited data will be > handled differently than solicited data. The target can chose where > the solicited data is delivered, but unsolicited data arrives through > a general-delivery path. Therefore, if the offered unsolicited data > burst size approaches the regular burst size, an implementation will > need TWICE as much buffer memory (half in the general-delivery area > and half in the flow-controlled buffer area) to support the same > operation load. Maybe this tradeoff is OK, but given the cost > sensitivity of storage targets, I doubt it. > > As always, I welcome comments from those who see things differently. > > Steph > From owner-ips@ece.cmu.edu Thu Jun 7 18:30:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15484 for ; Thu, 7 Jun 2001 18:30:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57L7XS04695 for ips-outgoing; Thu, 7 Jun 2001 17:07:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57L6fg04614 for ; Thu, 7 Jun 2001 17:06:41 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.177]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MG0NBS6Z; Thu, 7 Jun 2001 17:06:30 -0400 Reply-To: From: "Eddy Quicksall" To: Subject: iSCSI: text commands that set mode parameters Date: Thu, 7 Jun 2001 17:05:58 -0400 Message-ID: <003401c0ef95$a7045b20$b101a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm not crazy about setting mode parameters from text commands because the mode pages are in logic which is outside of iSCSI. Section 3 - SCSI Mode Parameters for iSCSI says: The mode parameters can be set and retrieved by SCSI mode-set and mode-sense commands or with the iSCSI text commands and responses. The text commands offer the added convenience that at the end of the exchange the value selected is known to both parties. I agree with the spirit of the last sentence above but I still think the logic is misplaced. Has anyone debated this yet? Does anyone else share my opinion? Is there a good reason to have the iSCSI layer do this? Can we talk about this or is there a thread I should review? Eddy From owner-ips@ece.cmu.edu Thu Jun 7 18:34:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15526 for ; Thu, 7 Jun 2001 18:34:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57KWhp01901 for ips-outgoing; Thu, 7 Jun 2001 16:32:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57KWgg01897 for ; Thu, 7 Jun 2001 16:32:42 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA104938 for ; Thu, 7 Jun 2001 15:27:10 -0500 Received: from f3n41e (d03nm041h.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f57KVOv76752 for ; Thu, 7 Jun 2001 14:31:25 -0600 Importance: Normal Subject: iSCSI: Send Targets and Report Portal Groups To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Kaladhar Voruganti" Date: Thu, 7 Jun 2001 21:31:22 +0100 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/07/2001 01:31:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, I am supporting your solution because it is a compromise, and there are many who are already using the SendTarget discovery method. Reasons for having it (others can add to this list): 1) Already many implementations are using it. 2) Purists will argue that it is a simple discovery method and not a management mechanism. 3 ) Can use the same Login and authentication mechanism as iSCSI. 4) iSCSI will not be the first protocol to have an in-band discovery mechanism (Report_Luns in SCSI). 5) Simple implementations will not have to use SLP or iSNS. Reasons for not having it (others can add to this list): 1) Do not want discovery mechanism as part of the protocol. 2) It will continue to evolve and is not as simple as it seems. 3) IETF standards approving body will have a problem with it, and this will delay the approval of the whole standard. 4) Can use SLP or iSNS to get the same functionality, and we can piggyback on the future enhancements to these discovery protocols. If we do keep the SendTarget command, then I want the following two points clarified: 1) If we keep SendTargets in version 1 annex, will it still be optional to implement? 2) What is the impact (if any) of passing digital certificates with the SendTarget response? I also agree that there is a need for a Report Portal Groups type of command. I will let people argue whether it is a separate issue than the SendTargets command. Kaladhar ---------------------- Forwarded by Kaladhar Voruganti/Almaden/IBM on 06/07/2001 12:59 PM --------------------------- John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 06/06/2001 07:34:01 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: Send Targets and Report Portal Groups iSCSI Team, I would like to propose the following approaches to address the issues of Send-Targets, and Report Portal Groups. The way Send-Targets has evolved, which is now a separate interaction with its own Login, makes it seem like the same function can be rationally performed by current Discovery Functions in SLP or iSNS. Now this is not completely correct, but close enough for me to propose a compromise. Before I state the compromise let me address the items that are current concerns with an SLP or iSNS approach of replacing Send-Targets. 1. The current SLP Open Source does not do a Unicast to ask for the information. This is not a shortcoming of the SLP protocol, just the current API/Implementation. Mark Bakke has made a Hack into the Open Source and believes that it will work just fine, and also thinks he has support for that approach from the Owners of the Open Source. However, there is still some uncertainty here, which will only be cleared up with time and multiple implementations. 2. There are separate Authentication models followed by SLP/iSNS as opposed to iSCSI. Therefore, any Initiator attempting to do SLP or iSNS for basic discovery, needs to address two Authentication models, the discovery method's authentication approach, and iSCSI's. 3. In small installations it is not clear that there will be an SLP or iSNS setup on which to leverage this approach. Now, I am cretin there will be arguments about the importance of any of those points, the issue is -- the uncertainty of favorable results. I am of the belief that it maybe worth the effort to move in the direction of "atrophying" the Send Targets Command and Processes. That is, it serves a current and valuable function, of which a favorable replacement, though probable, is uncertain at this time. So we should begin moving in the direction of the SLP/iSNS approach, but without additional care and feeding of Send Targets. An approach to this is to move the Send Target Command and Processes, into an Annex of the main iSCSI protocol document. As such it will be a current requirement for implementation, but it will also be clear that we believe it may be eliminated in version 2 of the iSCSI document (when ever that occurs) and is not something in which feature creep will be permitted. I think the above approach will satisfy the folks that have been building and testing various product approaches that depend on Send Targets, and yet give them time to move to an SLP or iSNS type approach as the concerns specified above are worked out. It is also possible that in the future, we will find that we are fundamentally wrong in some of our key assumptions, and that Version 2 may move it back into the main document. That would also be acceptable, because I do not believe it would happen lightly, and would have to have great reasoning and logic behind such a move. Now, I would like to address the Report Portal Groups. I do not place this in the same category as Send Targets. It is a specific query about the environment of the specific session in which the command is issued. It is analogous to Report LUNs, and querying Mode Pages. For those of you that have not been following this closely, the Report Portal Groups, is a command that responds with the IP addresses that can be used by the initiator of the current session, to add additional connections to the current session (and thereby support Multiple Connections per Session). It is specific to its own session, and not to some general management item. Some might say that this too could be discovered by some management function, however, that could also be true about many of the Mode Page setting also. In my opinion the Portal Groups will probably be "wired in" by the Storage Controller vendor and not be something that is settable by the administrator. In fact with Report Portal Groups, being part of the base protocol, the SLP/iSNS (or the Send Targets Command) will not have to include the portal group identification/tagging in its responses, thus simplifying them. So as part of my proposed compromise I recommend that we put "Report Portal Groups" into the main iSCSI Protocol Document, like any of the other iSCSI Commands, and move the Send-Targets command to an Annex as specified above. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Thu Jun 7 20:26:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16511 for ; Thu, 7 Jun 2001 20:26:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57MQtl10275 for ips-outgoing; Thu, 7 Jun 2001 18:26:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57MQrg10267 for ; Thu, 7 Jun 2001 18:26:53 -0400 (EDT) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel2.hp.com (Postfix) with ESMTP id 735D6109B for ; Thu, 7 Jun 2001 15:26:52 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 6EFA11F516 for ; Thu, 7 Jun 2001 15:24:58 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 15:25:59 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A090DC@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI: Send Targets and Report Portal Groups Date: Thu, 7 Jun 2001 15:25:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > Reasons for not having it (others can add to this list): > 1) Do not want discovery mechanism as part of the protocol. > 2) It will continue to evolve and is not as simple as it seems. > 3) IETF standards approving body will have a problem with it, > and this will > delay the approval of the whole standard. > 4) Can use SLP or iSNS to get the same functionality, and we > can piggyback > on the future enhancements to these discovery protocols. 5)There is also the viewpoint that a transport protocol should contain only what's necessary for establishing a transport link and keeping that link functioning. (eg, TCP connection establishment, SYN exchange) Any other configuration data exchange is a management function that should use a generic data exchange/mgmt protocol (SLP? DHCP? SNMP? XML?). Or iSNS. Given this purist viewpoint, there is a clear difference between the other text commands in iSCSI and the SendTargets or ReportPortalGroups text commands. IMO, it's a judgement call where you draw the line between architectural purity and practical functional encapsulation. My current feeling is that a limited SendTargets function adds a small amount of implementation burden and a large amount of functional value to product solutions. Given the nature and deployment of storage devices, the reporting of minimal 'iSCSI connectivity information' in the iSCSI protocol enables a powerful capability for 'plug-n-play' at a minimal cost. The fact that SLP and iSCSI have different authentication models and points of control is a large factor in support of SendTargets - authentication management is a huge burden for customers. (Of course that fact could start a whole nother thread cause this is a common problem between various IP-based protocols). ReportPortalGroups feels like feature-creep to me given that it's a subset of SendTargets. I agree with Mallikarjun, moving SendTargets to an 'annex' doesn't seem appropriate when viewed thru his logic, and we should strip out fluff like "TargetAlias", which is clearly 'value-add' more appropriate to a MIB or some other management interface. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com From owner-ips@ece.cmu.edu Thu Jun 7 20:28:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16539 for ; Thu, 7 Jun 2001 20:28:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57MhQx11325 for ips-outgoing; Thu, 7 Jun 2001 18:43:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f57MhOg11321 for ; Thu, 7 Jun 2001 18:43:24 -0400 (EDT) Received: from daniel ([213.10.179.111]) by smtp04.wxs.nl (Netscape Messaging Server 4.05) with SMTP id GEL0G102.9VC; Fri, 8 Jun 2001 00:43:13 +0200 Message-ID: <006101c0efa4$40e77700$9600000a@daniel> From: "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: , Cc: References: <200106071805.LAA16712@core.rose.hp.com> Subject: Re: Unsolicited Data. Date: Fri, 8 Jun 2001 00:50:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallkarjun, According to me it is possible for initiator **not** to send unsolicited data if we follow the latest changes on the section 2.3.1 posted at According to me When IntitialR2T= No, Immediate Data = Yes and target doesnt want to send any immediate data but it does want to send unsolicited data it can be done like this Step 1 Send iSCSI CmdPDU and Dont send F bit and Dont send any immediate data by not including any extra length in datasegmentlength Step 2 Send Unsolicited Data and set the F bit When IntitialR2T= No, Immediate Data = Yes and target doesnt want to send any immediate data nor does it want to send unsolicited data it can be done as follows Set F bit in Task and Flag Attributes and dont send any immediate data by not including any extra length in datasegmentlength . My only doubt here is that it is not any illegal condition to set this F bit when there is no immediate data to be sent and no unsolicited data to be sent. Current spec doesnt declare it illegal but it doesnt really suggest it this way either. PLEASE DO COMMENT ON THIS Regards, Sanjeev ----- Original Message ----- From: "Mallikarjun C." To: Cc: Sent: Thursday, June 07, 2001 8:04 PM Subject: Re: Unsolicited Data. > Steph, > > I agree with you that mandating unsolicited data to be sent always > is limiting, even if InitialR2T=no is negotiated. > > I suggest the following for consideration - > - If the command F-bit is set: > - if immediate data is present, it's all the data > for the command. (as in rev06) > - if immediate data is not present, there are no > unsolicited data PDUs following. > - If the command F-bit is not set: > - if immediate is present, there is more solicited > data to follow. > - if immediate data is not present, there may be > solicited data depending on "Expected Data Transfer > Length". > > The only case this disallows is that of having _both_ unsolicited > separate PDUs and immediate data for a command - which I personally > am okay with. This is disallowed in rev06 anyway, but for some > reason seemed like was changed later. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > > >Sanjeev, > > > >> why would initiator choose not to send unsolicited immediate data when > >> it has negotiated for IntialR2T= Yes?? > > > >I assume you mean InitialR2T=no. > > > >I would do this because I think that the real benefit of unsolicited > >data is for writes where ALL the write data can be sent unsolicited, > >and I'm happy to have the target schedule the transfer of (ALL) data > >for larger writes. Of course, others would say I'm a moron. > > > >Assuming the overwhelming majority of storage use is file access, > >small writes are exclusively file system metadata writes. Unsolicited > >data is a huge win for metadata writes because the latency of these > >metadata writes is frequently not covered by transferring other data > >(within a single access thread). On the other hand, the file system > >(usually) generates enough concurrent demand for real data writes that > >the flow control (R2T) latency is well hidden. > > > >You might argue that if you're running a file system optimized fors > >today's SANs over a link with a HUGE bandwidth * delay product > >(greater than the expected demand created by the file system), sending > >large amounts of unsolicited write data will substantially improve the > >link utilization. That is true, but I don't think many targets are > >going to offer unsolicited data bursts remotely that large. > > > >In a hardware accelerate implementation, unsolicited data will be > >handled differently than solicited data. The target can chose where > >the solicited data is delivered, but unsolicited data arrives through > >a general-delivery path. Therefore, if the offered unsolicited data > >burst size approaches the regular burst size, an implementation will > >need TWICE as much buffer memory (half in the general-delivery area > >and half in the flow-controlled buffer area) to support the same > >operation load. Maybe this tradeoff is OK, but given the cost > >sensitivity of storage targets, I doubt it. > > > >As always, I welcome comments from those who see things differently. > > > >Steph > > > > From owner-ips@ece.cmu.edu Thu Jun 7 21:44:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18244 for ; Thu, 7 Jun 2001 21:44:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f57Nloc15421 for ips-outgoing; Thu, 7 Jun 2001 19:47:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f57Nlmg15414 for ; Thu, 7 Jun 2001 19:47:48 -0400 (EDT) Received: (cpmta 821 invoked from network); 7 Jun 2001 16:47:37 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.221) with SMTP; 7 Jun 2001 16:47:37 -0700 X-Sent: 7 Jun 2001 23:47:37 GMT From: "Douglas Otis" To: "Mark Bakke" , "Venkat Rangan" Cc: , Subject: RE: iSCSI: Nailing down CRC-32C Date: Thu, 7 Jun 2001 16:45:18 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B1F9411.2F6FE378@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, I have attempted to provide a reference implementation for SCTP in this draft. Ignore all but the CRC algorithm. ftp://ftp.sanlight.net/pub/draft-otis-sctp-digest-01.txt Doug > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mark Bakke > Sent: Thursday, June 07, 2001 7:48 AM > To: Venkat Rangan > Cc: 'julian_satran@il.ibm.com'; ips@ece.cmu.edu > Subject: Re: iSCSI: Nailing down CRC-32C > > > Venkat- > > Sorry for the high-latency response; it took a while to > get back to this thread. Anyway, I don't see any particular > reason why the bit ordering has to be one way or the other, > except that it will be easier for everyone if we do the > reflection both in and out, since it will match what is > done on Ethernet, Fibre Channel, and ultra-SCSI. Looking > at these documents, I think that the simplest and least > ambiguous description of the CRC is in the T10 SPI-3 > (rev 14, page 121). It includes a description of the > bit ordering, as well as a few simple test cases. It's > at: > > ftp://ftp.t10.org/t10/drafts/spi3/spi3r14.pdf > > Julian, I think that the last data integrity section you > had sent covers everything except the bit ordering. If we > copied the statement: > > Bytes are bit reversed prior to generating the remainder > and the bytes of the remainder are bit reversed prior to > forming the CRC field. > > from the T10 doc, I think that everything else is specified. > > It would then be helpful as a check to include a few test > cases that people could run. I took the T10 test cases, and > ran them through with (my interpretation of) the iSCSI > CRC-32C: > > For a 32-byte transfer of all 00h, the CRC will be 8A9136AA > (the most significant byte would be the first byte transmitted > on the network interface). > > For a 32-byte transfer of all FFh, the CRC will be 62A8AB43. > > For a 32-byte incrementing test pattern of bytes starting with > 00h and ending with 1Fh, in network order, the CRC will be > 46DD794E. > > This should be sufficient for someone to test their hardware > or software implementation of the iSCSI CRC, and ensure that > it will be interoperable. If desired, we could also make up > a sample iSCSI header (perhaps an inquiry command or something > equally common), along with its expected CRC. > > Can we add the above statements on bit ordering and test cases > to the draft-07? It will give us the best possible chance of > everyone's implementation of the CRC to match the first time. > > -- > Mark > > Venkat Rangan wrote: > > > > Mark, > > > > Is there any specific advantage to iSCSI Reflection Parameters > > to be different from that of Ethernet? Does CRC32-C benefit by > > a different set of parameters? If so, what are they, and how do we > > get closure on a particular set of parameters? > > > > Purely from the description of the parameters, RefIn=TRUE means > that each > > byte from the stream is 'reflected' so that bit 0 is fed in first and > > then bit 1 etc. RefOut=TRUE means that the 32-bit value of the > CRC is also > > reflected before the final XOR is done. > > > > Currently, Ethernet has 'RefIn=TRUE' and 'RefOut= TRUE'. > > > > Thanks, > > > > Venkat Rangan > > Rhapsody Networks Inc. > > http://www.rhapsodynetworks.com > > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Tuesday, May 15, 2001 5:16 AM > > To: Venkat Rangan > > Cc: 'julian_satran@il.ibm.com'; ips@ece.cmu.edu > > Subject: Re: iSCSI: Nailing down CRC-32C > > > > Venkat- > > > > I assumed the same parameters (iSCSI has not yet specified > > the reflection parameters), and obtained the same check you > > did with their code. > > > > -- > > Mark > > > > Venkat Rangan wrote: > > > > > > All, > > > > > > Based on the finalization of the parameters of CRC-32C per following > > > parameters, I obtained a check of 0xE3069283 for the > nine-byte string of > > > "123456789" (9 bytes) that the Rocksoft CRC document refers to. > > > > > > Name : "CRC-32C" > > > Width : 32 > > > Poly : 1EDC6F41 (note that the leading "1" is implied) > > > Init : FFFFFFFF > > > RefIn : True > > > RefOut : True > > > XorOut : FFFFFFFF > > > Check : E3069283 > > > > > > It would be nice if other independant checks can validate this. > > > > > > Venkat Rangan > > > Rhapsody Networks Inc. > > > http://www.rhapsodynetworks.com > > > > > > The table and code follows: > > > > > > /*****************************************************************/ > > > /* */ > > > /* CRC LOOKUP TABLE */ > > > /* ================ */ > > > /* The following CRC lookup table was generated automagically */ > > > /* by the Rocksoft^tm Model CRC Algorithm Table Generation */ > > > /* Program V1.0 using the following model parameters: */ > > > /* */ > > > /* Width : 4 bytes. */ > > > /* Poly : 0x1EDC6F41L */ > > > /* Reverse : TRUE. */ > > > /* */ > > > /* For more information on the Rocksoft^tm Model CRC Algorithm, */ > > > /* see the document titled "A Painless Guide to CRC Error */ > > > /* Detection Algorithms" by Ross Williams */ > > > /* (ross@guest.adelaide.edu.au.). This document is likely to be */ > > > /* in the FTP archive "ftp.adelaide.edu.au/pub/rocksoft". */ > > > /* */ > > > /*****************************************************************/ > > > > > > unsigned long crctable[256] = > > > { > > > 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, > > > 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, > > > 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, > > > 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, > > > 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, > > > 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, > > > 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, > > > 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, > > > 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, > > > 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, > > > 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, > > > 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, > > > 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, > > > 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, > > > 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, > > > 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, > > > 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, > > > 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, > > > 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, > > > 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, > > > 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, > > > 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, > > > 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, > > > 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, > > > 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, > > > 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, > > > 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, > > > 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, > > > 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, > > > 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, > > > 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, > > > 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, > > > 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, > > > 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, > > > 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, > > > 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, > > > 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, > > > 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, > > > 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, > > > 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, > > > 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, > > > 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, > > > 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, > > > 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, > > > 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, > > > 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, > > > 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, > > > 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, > > > 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, > > > 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, > > > 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, > > > 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, > > > 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, > > > 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, > > > 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, > > > 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, > > > 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, > > > 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, > > > 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, > > > 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, > > > 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, > > > 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, > > > 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, > > > 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L > > > }; > > > > > > /*****************************************************************/ > > > /* End of CRC Lookup Table */ > > > /*****************************************************************/ > > > > > > /*****************************************************************/ > > > /* ComputeCRC */ > > > /*****************************************************************/ > > > #include > > > #include > > > #include "crctable.h" > > > > > > #define TB_INIT 0xFFFFFFFF > > > #define TB_INIT_REFLECTED 0xFFFFFFFF > > > #define TB_XOROT 0xFFFFFFFF > > > > > > unsigned long crc_reflected (); > > > unsigned long crc_reflected (blk_adr,blk_len) > > > unsigned char *blk_adr; > > > unsigned long blk_len; > > > { > > > unsigned long crc = TB_INIT_REFLECTED; > > > while (blk_len--) > > > crc = crctable[(crc ^ *blk_adr++) & 0xFFL] ^ (crc >> 8); > > > return crc ^ TB_XOROT; > > > } > > > > > > -----Original Message----- > > > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] > > > Sent: Tuesday, May 08, 2001 7:38 AM > > > To: ips@ece.cmu.edu > > > Subject: Re: iSCSI: Nailing down CRC-32C > > > > > > Mark, > > > > > > My basic assumption was that everything is (as in all IP related > > standards) > > > in network order. > > > > > > Regards, > > > Julo > > > > > > Mark Bakke on 07-05-2001 23:00:28 > > > > > > Please respond to Mark Bakke > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: Nailing down CRC-32C > > > > > > Julian- > > > > > > That's great; it covers nearly everything. The only thing left > > > is the byte order; are they taken in the same order Ethernet uses? > > > > > > If so, I can generate a few test patterns that our implementations > > > can all check against. > > > > > > Thanks, > > > > > > -- > > > Mark > > > > > > julian_satran@il.ibm.com wrote: > > > > > > > > The CRC part of the appendix (for 07) reads: > > > > > > > > The following table lists cyclic integrity checksums that can be > > > > negotiated for the digests and MUST be implemented by every iSCSI > > > > initiator and target. Note that these digest options > have only error > > > > detection significance. > > > > > > > > +---------------------------------------------+ > > > > | Name | Description | > > > > +---------------------------------------------+ > > > > | crc-32C | 32 bit CRC | 11EDC6F41 | > > > > +---------------------------------------------+ > > > > | none | no digest | > > > > +---------------------------------------------+ > > > > > > > > The generator polynomials for those digests are given in > > hex-notation, > > > > for example 3a stands for 0011 1010 - the polynomial > > > x**5+X**4+x**3+x+1. > > > > > > > > The generator polynomial selected is evaluated in > [Castagnioli93]. > > > > When using the CRC the CRC register must be initialized to all 1s > > > > (0xFFFFFFFF) and the CRC bits must be complemented before > > > transmission. > > > > Padding bytes, when presents in a segment covered by a > CRC, have to > > be > > > > set to 0 and are included in the CRC. > > > > > > > > Regards, > > > > Julo > > > > > > > > Mark Bakke on 05-05-2001 00:13:09 > > > > > > > > Please respond to Mark Bakke > > > > > > > > To: IPS > > > > cc: > > > > Subject: iSCSI: Nailing down CRC-32C > > > > > > > > At the interim meeting, it was stated that iSCSI has selected > > > > the CRC-32C polynomial as its required iSCSI-level header and > > > > data CRC. Now that we have it, it's time to move on and make > > > > sure we can implement it. > > > > > > > > In the interest of interoperability, we need to not only specify > > > > the polynomial, but also the initial values, bit and byte > > > > ordering, etc. > > > > > > > > "A Painless Guide to CRC Error Detection Algorithms" > > > > (http://www.ross.net/crc/crcpaper.html) specifies a > > > > method to unambiguously characterize these parameters > > > > (sections 15 and 16). Has anyone taken a shot at defining > > > > these yet? Otherwise, here is what it might look like: > > > > > > > > Name : "CRC-32C" > > > > Width : 32 > > > > Poly : 1EDC6F41 (note that the leading "1" is implied) > > > > Init : FFFFFFFF > > > > RefIn : True > > > > RefOut : True > > > > XorOut : FFFFFFFF > > > > Check : ? > > > > > > > > I haven't attempted to create check data based on these yet. As > > > > soon as the other parameters are nailed down, we need to do this. > > > > > > > > Anyway, I am not a CRC expert, and can't make any statement about > > > > the above values being the "best" way to do this, but instead just > > > > copied them (except the polynomial itself) from the Ethernet CRC, > > > > since that is likely the easiest for everyone implementing hardware > > > > to deal with. > > > > > > > > If someone else is already doing this, let me know; I just wanted > > > > to start this thread so we can get closure. > > > > > > > > Regards, > > > > > > > > Mark > > > > > > > > -- > > > > Mark A. Bakke > > > > Cisco Systems > > > > mbakke@cisco.com > > > > 763.398.1054 > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Thu Jun 7 21:45:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18256 for ; Thu, 7 Jun 2001 21:45:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f580FDM17053 for ips-outgoing; Thu, 7 Jun 2001 20:15:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f580FBg17048 for ; Thu, 7 Jun 2001 20:15:12 -0400 (EDT) Received: (cpmta 28286 invoked from network); 7 Jun 2001 17:15:05 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.219) with SMTP; 7 Jun 2001 17:15:05 -0700 X-Sent: 8 Jun 2001 00:15:05 GMT From: "Douglas Otis" To: "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Subject: RE: iSCSI: Send Targets and Report Portal Groups Date: Thu, 7 Jun 2001 17:12:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87802A090DC@xrose06.rose.hp.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Marjorie, This leads to feature creep where eventually all management is placed upon the transport. Any such management at this point will still need to come from some other management scheme or this does not allow for promulgation or coherency and will lead to vendor unique solutions. I would be in favor of removing as much away from the transport and instead converge on an existing management server. I would hope the signaling desired could be done by those entities that either identify or instrument a change and then those entities signal effected servers of these changes. Doug > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > KRUEGER,MARJORIE (HP-Roseville,ex1) > Sent: Thursday, June 07, 2001 3:26 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: Send Targets and Report Portal Groups > > > > Reasons for not having it (others can add to this list): > > 1) Do not want discovery mechanism as part of the protocol. > > 2) It will continue to evolve and is not as simple as it seems. > > 3) IETF standards approving body will have a problem with it, > > and this will > > delay the approval of the whole standard. > > 4) Can use SLP or iSNS to get the same functionality, and we > > can piggyback > > on the future enhancements to these discovery protocols. > > 5)There is also the viewpoint that a transport protocol should > contain only > what's necessary for establishing a transport link and keeping that link > functioning. (eg, TCP connection establishment, SYN exchange) Any other > configuration data exchange is a management function that should use a > generic data exchange/mgmt protocol (SLP? DHCP? SNMP? XML?). Or iSNS. > Given this purist viewpoint, there is a clear difference between the other > text commands in iSCSI and the SendTargets or ReportPortalGroups text > commands. > > IMO, it's a judgement call where you draw the line between architectural > purity and practical functional encapsulation. My current > feeling is that a > limited SendTargets function adds a small amount of implementation burden > and a large amount of functional value to product solutions. Given the > nature and deployment of storage devices, the reporting of minimal 'iSCSI > connectivity information' in the iSCSI protocol enables a powerful > capability for 'plug-n-play' at a minimal cost. The fact that > SLP and iSCSI > have different authentication models and points of control is a > large factor > in support of SendTargets - authentication management is a huge burden for > customers. (Of course that fact could start a whole nother thread cause > this is a common problem between various IP-based protocols). > > ReportPortalGroups feels like feature-creep to me given that it's a subset > of SendTargets. > > I agree with Mallikarjun, moving SendTargets to an 'annex' doesn't seem > appropriate when viewed thru his logic, and we should strip out fluff like > "TargetAlias", which is clearly 'value-add' more appropriate to a MIB or > some other management interface. > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > tel: +1 916 785 2656 > fax: +1 916 785 0391 > email: marjorie_krueger@hp.com > From owner-ips@ece.cmu.edu Thu Jun 7 22:07:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18548 for ; Thu, 7 Jun 2001 22:07:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f580mer18996 for ips-outgoing; Thu, 7 Jun 2001 20:48:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f580mSg18990 for ; Thu, 7 Jun 2001 20:48:29 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id 04A9F1D06 for ; Thu, 7 Jun 2001 17:48:28 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id RAA20503 for ips@ece.cmu.edu; Thu, 7 Jun 2001 17:49:37 -0700 (PDT) Message-Id: <200106080049.RAA20503@core.rose.hp.com> Subject: Re: Unsolicited Data. To: ips@ece.cmu.edu Date: Thu, 07 Jun 2001 17:49:36 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Sanjeev, You seem to restate what I proposed at the bottom of this email. Yes, the current draft doesn't talk about F-bit setting when immediate data is not present. That's precisely what my proposal attempts to make use of - to signal "no unsolicited data" if the F-bit is set. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >Mallkarjun, > >According to me it is possible for initiator **not** to send unsolicited >data if we follow the latest changes on the section 2.3.1 posted at > >According to me > >When IntitialR2T= No, Immediate Data = Yes and target doesnt want to >send any immediate data but it does want to send unsolicited data it can be >done like this >Step 1 >Send iSCSI CmdPDU and Dont send F bit and Dont send any immediate data by >not including any extra length in datasegmentlength >Step 2 >Send Unsolicited Data and set the F bit > > >When IntitialR2T= No, Immediate Data = Yes and target doesnt want to >send any immediate data nor does it want to send unsolicited data it can be >done as follows > >Set F bit in Task and Flag Attributes and dont send any immediate data >by not including any extra length in datasegmentlength . > >My only doubt here is that it is not any illegal condition to set this F bit >when there is no immediate data to be sent and no unsolicited data to be >sent. Current spec doesnt declare it illegal but it doesnt really suggest it >this way either. > > >PLEASE DO COMMENT ON THIS > >Regards, >Sanjeev > > > > >----- Original Message ----- >From: "Mallikarjun C." >To: >Cc: >Sent: Thursday, June 07, 2001 8:04 PM >Subject: Re: Unsolicited Data. > > >> Steph, >> >> I agree with you that mandating unsolicited data to be sent always >> is limiting, even if InitialR2T=no is negotiated. >> >> I suggest the following for consideration - >> - If the command F-bit is set: >> - if immediate data is present, it's all the data >> for the command. (as in rev06) >> - if immediate data is not present, there are no >> unsolicited data PDUs following. >> - If the command F-bit is not set: >> - if immediate is present, there is more solicited >> data to follow. >> - if immediate data is not present, there may be >> solicited data depending on "Expected Data Transfer >> Length". >> >> The only case this disallows is that of having _both_ unsolicited >> separate PDUs and immediate data for a command - which I personally >> am okay with. This is disallowed in rev06 anyway, but for some >> reason seemed like was changed later. >> -- >> Mallikarjun >> >> >> Mallikarjun Chadalapaka >> Networked Storage Architecture >> Network Storage Solutions Organization >> MS 5668 Hewlett-Packard, Roseville. >> cbm@rose.hp.com >> >> > >> >Sanjeev, >> > >> >> why would initiator choose not to send unsolicited immediate data when >> >> it has negotiated for IntialR2T= Yes?? >> > >> >I assume you mean InitialR2T=no. >> > >> >I would do this because I think that the real benefit of unsolicited >> >data is for writes where ALL the write data can be sent unsolicited, >> >and I'm happy to have the target schedule the transfer of (ALL) data >> >for larger writes. Of course, others would say I'm a moron. >> > >> >Assuming the overwhelming majority of storage use is file access, >> >small writes are exclusively file system metadata writes. Unsolicited >> >data is a huge win for metadata writes because the latency of these >> >metadata writes is frequently not covered by transferring other data >> >(within a single access thread). On the other hand, the file system >> >(usually) generates enough concurrent demand for real data writes that >> >the flow control (R2T) latency is well hidden. >> > >> >You might argue that if you're running a file system optimized fors >> >today's SANs over a link with a HUGE bandwidth * delay product >> >(greater than the expected demand created by the file system), sending >> >large amounts of unsolicited write data will substantially improve the >> >link utilization. That is true, but I don't think many targets are >> >going to offer unsolicited data bursts remotely that large. >> > >> >In a hardware accelerate implementation, unsolicited data will be >> >handled differently than solicited data. The target can chose where >> >the solicited data is delivered, but unsolicited data arrives through >> >a general-delivery path. Therefore, if the offered unsolicited data >> >burst size approaches the regular burst size, an implementation will >> >need TWICE as much buffer memory (half in the general-delivery area >> >and half in the flow-controlled buffer area) to support the same >> >operation load. Maybe this tradeoff is OK, but given the cost >> >sensitivity of storage targets, I doubt it. >> > >> >As always, I welcome comments from those who see things differently. >> > >> >Steph >> > >> >> > From owner-ips@ece.cmu.edu Thu Jun 7 22:11:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18617 for ; Thu, 7 Jun 2001 22:11:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5819ss20215 for ips-outgoing; Thu, 7 Jun 2001 21:09:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5819qg20206 for ; Thu, 7 Jun 2001 21:09:52 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 18:09:47 -0700 Message-ID: From: Joshua Tseng To: ips@ece.cmu.edu Subject: iSCSI: IP fragmentation Date: Thu, 7 Jun 2001 18:09:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, IP fragmentation is an issue which will affect the performance, logic and HBA/NIC memory requirements of iSCSI implementations. Note that fragmentation by intermediary switches and routers is not permitted in IPv6 (hence, the DO NOT FRAGMENT bit does not exist in IPv6). With this in mind, and in the interest of optimizing iSCSI performance, I was wondering if it would make sense to require that the DO NOT FRAGMENT bit to be set on IPv4 packets carrying iSCSI and that iSCSI implementations not perform IP fragmentation for IPv6. This will allow for performance optimization if implementations do not have to check for fragmentation and handle reassembly. Any thoughts? Josh From owner-ips@ece.cmu.edu Fri Jun 8 00:34:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21311 for ; Fri, 8 Jun 2001 00:34:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f582dP425406 for ips-outgoing; Thu, 7 Jun 2001 22:39:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f582dNg25402 for ; Thu, 7 Jun 2001 22:39:23 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 19:39:16 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE6506CE55@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Joshua Tseng'" , ips@ece.cmu.edu Subject: RE: iSCSI: IP fragmentation Date: Thu, 7 Jun 2001 19:39:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Josh, I think this is a good idea. Does this mean we should do a MTU discovery on the path between the iSCSI initiator and target so that we can do intelligent DataPDULength selection. Maybe the default is to keep the DataPDULength at 2 units (1 unit = 512 bytes) to avoid fragmentation, assuming the interface at the two ends are Ethernet. -dennis -----Original Message----- From: Joshua Tseng [mailto:jtseng@NishanSystems.com] Sent: Thursday, June 07, 2001 6:10 PM To: ips@ece.cmu.edu Subject: iSCSI: IP fragmentation Folks, IP fragmentation is an issue which will affect the performance, logic and HBA/NIC memory requirements of iSCSI implementations. Note that fragmentation by intermediary switches and routers is not permitted in IPv6 (hence, the DO NOT FRAGMENT bit does not exist in IPv6). With this in mind, and in the interest of optimizing iSCSI performance, I was wondering if it would make sense to require that the DO NOT FRAGMENT bit to be set on IPv4 packets carrying iSCSI and that iSCSI implementations not perform IP fragmentation for IPv6. This will allow for performance optimization if implementations do not have to check for fragmentation and handle reassembly. Any thoughts? Josh From owner-ips@ece.cmu.edu Fri Jun 8 09:34:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12323 for ; Fri, 8 Jun 2001 09:34:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58BMLi06504 for ips-outgoing; Fri, 8 Jun 2001 07:22:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tiny-teddy.aarnet.edu.au (IDENT:root@tiny-teddy.aarnet.edu.au [203.21.37.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5860Qg07301 for ; Fri, 8 Jun 2001 02:00:27 -0400 (EDT) Received: from aarnet.edu.au (gt1.aarnet.adelaide.edu.au [129.127.180.236]) by tiny-teddy.aarnet.edu.au (8.11.0/8.11.0) with ESMTP id f5860Gw22083; Fri, 8 Jun 2001 15:30:16 +0930 Message-ID: <3B2069E5.C1795E8@aarnet.edu.au> Date: Fri, 08 Jun 2001 15:30:05 +0930 From: Glen Turner Organization: Australian Academic and Research Network X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-ac11-mpls0.990-usbpwc7.01-gdt2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Joshua Tseng CC: ips@ece.cmu.edu Subject: Re: iSCSI: IP fragmentation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Joshua Tseng wrote: > > I was wondering if it would make sense to require that the > DO NOT FRAGMENT bit to be set on IPv4 packets carrying iSCSI Hosts already SHOULD do path MTU discovery, so it is not the sender who's behaviour you are specifing, but the behaviour of the receiver. I think you are asking that the reciever of iSCSI IP packets with DF=0 send a ICMP error, or drop the packets quietly. If the receiver sends an ICMP, how do you prevent malicious unauthenticated people from using iSCSI receivers as denial of service multiplers? If the receiver doesn't send an ICMP, how do users discover the configuration error? It is also not clear to me how you would implement this proposal on a general purpose operating system (that is, on many iSCSI initiators) where the Path MTU feature is globally set for all protocols. The mere act of checking the DF bit may prove difficult on some platforms. For example a mainframe that does TCP offload will have no idea what the DF bit of an individual IP packet is, and to find out will cost many more channel accesses than allowing fragment reassembly on the offload processor. Finally, and most significantly, I would oppose your suggestion simply because it is a long-held IETF design philosophy that receivers should be robust. The best IETF standards also avoid prescribing implementation optimisations, leaving these for less normative informational RFCs. Until we have more experience with the protocol in practice, it would seem to me unwise to seek to optimise unbenchmarked performance. I suggest that your proposal only considers one of the two partners in a iSCSI session, the target. Be careful in that optimising the target performance you don't reduce the initiator performance and suboptimize the system. Glen -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- The revolution will not be televised, it will be digitised From owner-ips@ece.cmu.edu Fri Jun 8 11:41:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14651 for ; Fri, 8 Jun 2001 11:41:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58DWbP14624 for ips-outgoing; Fri, 8 Jun 2001 09:32:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from webmail.sanvalley.com (100.winstar.net [216.172.186.100] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58DWag14619 for ; Fri, 8 Jun 2001 09:32:36 -0400 (EDT) Received: by webmail.sanvalley.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Jun 2001 06:28:14 -0700 Message-ID: <73DE11092C445F478CB3629910B2F49461A0BD@webmail.sanvalley.com> From: Glen Shok To: "'Glen Turner'" , Joshua Tseng Cc: ips@ece.cmu.edu Subject: RE: iSCSI: IP fragmentation Date: Fri, 8 Jun 2001 06:28:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk So taking a look at this from a network perspective, it depends where you want iSCSI to potentially be implemented. Doing MTU discovery in a private (leased line) network is not unrealistic as you have control over your routers, and you already know (for example) that you don't have MTU between any 2 points set below 1500. Yet if you would like iSCSI to be able to run over the public Internet or over a leased IP Service Provider Network, then you are unaware of what the "cloud" looks like. Most Service Providers, and the Internet will not send you back an ICMP (for security reasons) telling you why they dropped the packet, thus the frames will never make their way from the sender to receiver, and it will be almost impossible to debug why. I agree with Glen, you have got me make the receivers in an IP environment as robust as possible. You can't count on the network that you are sending your data over to be the perfect network. Glen Shok SAN Valley Systems -----Original Message----- From: Glen Turner [mailto:glen.turner@aarnet.edu.au] Sent: Thursday, June 07, 2001 11:00 PM To: Joshua Tseng Cc: ips@ece.cmu.edu Subject: Re: iSCSI: IP fragmentation Joshua Tseng wrote: > > I was wondering if it would make sense to require that the > DO NOT FRAGMENT bit to be set on IPv4 packets carrying iSCSI Hosts already SHOULD do path MTU discovery, so it is not the sender who's behaviour you are specifing, but the behaviour of the receiver. I think you are asking that the reciever of iSCSI IP packets with DF=0 send a ICMP error, or drop the packets quietly. If the receiver sends an ICMP, how do you prevent malicious unauthenticated people from using iSCSI receivers as denial of service multiplers? If the receiver doesn't send an ICMP, how do users discover the configuration error? It is also not clear to me how you would implement this proposal on a general purpose operating system (that is, on many iSCSI initiators) where the Path MTU feature is globally set for all protocols. The mere act of checking the DF bit may prove difficult on some platforms. For example a mainframe that does TCP offload will have no idea what the DF bit of an individual IP packet is, and to find out will cost many more channel accesses than allowing fragment reassembly on the offload processor. Finally, and most significantly, I would oppose your suggestion simply because it is a long-held IETF design philosophy that receivers should be robust. The best IETF standards also avoid prescribing implementation optimisations, leaving these for less normative informational RFCs. Until we have more experience with the protocol in practice, it would seem to me unwise to seek to optimise unbenchmarked performance. I suggest that your proposal only considers one of the two partners in a iSCSI session, the target. Be careful in that optimising the target performance you don't reduce the initiator performance and suboptimize the system. Glen -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- The revolution will not be televised, it will be digitised From owner-ips@ece.cmu.edu Fri Jun 8 12:40:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16114 for ; Fri, 8 Jun 2001 12:40:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58EOJi18329 for ips-outgoing; Fri, 8 Jun 2001 10:24:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f58EOHg18325 for ; Fri, 8 Jun 2001 10:24:17 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Fri Jun 8 10:22:09 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Fri Jun 8 10:22:54 EDT 2001 Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id KAA29028 for ; Fri, 8 Jun 2001 10:22:24 -0400 (EDT) Message-ID: <3B20DFA0.8FE21E6E@research.bell-labs.com> Date: Fri, 08 Jun 2001 10:22:24 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: Unsolicited Data. References: <200106080049.RAA20503@core.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit FYI..this has been discussed in an earlier thread. The final bit would indicate end-of-sequence, and then enable the target to start sending R2Ts. see http://ips.pdl.cs.cmu.edu/mail/msg04638.html And Matt had similar objections (as raised earlier in this thread) to allowing the initiator the leeway to decide if it can (or cannot) send the negotiated amount of immediate data. IOW, the draft does not state that the initiator MUST send the negotiated amount of data. -Sandeep "Mallikarjun C." wrote: > > Sanjeev, > > You seem to restate what I proposed at the bottom of this email. > > Yes, the current draft doesn't talk about F-bit setting when immediate > data is not present. That's precisely what my proposal attempts to > make use of - to signal "no unsolicited data" if the F-bit is set. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > >Mallkarjun, > > > >According to me it is possible for initiator **not** to send unsolicited > >data if we follow the latest changes on the section 2.3.1 posted at > > > >According to me > > > >When IntitialR2T= No, Immediate Data = Yes and target doesnt want to > >send any immediate data but it does want to send unsolicited data it can be > >done like this > >Step 1 > >Send iSCSI CmdPDU and Dont send F bit and Dont send any immediate data by > >not including any extra length in datasegmentlength > >Step 2 > >Send Unsolicited Data and set the F bit > > > > > >When IntitialR2T= No, Immediate Data = Yes and target doesnt want to > >send any immediate data nor does it want to send unsolicited data it can be > >done as follows > > > >Set F bit in Task and Flag Attributes and dont send any immediate data > >by not including any extra length in datasegmentlength . > > > >My only doubt here is that it is not any illegal condition to set this F bit > >when there is no immediate data to be sent and no unsolicited data to be > >sent. Current spec doesnt declare it illegal but it doesnt really suggest it > >this way either. > > > > > >PLEASE DO COMMENT ON THIS > > > >Regards, > >Sanjeev > > > > > > > > > >----- Original Message ----- > >From: "Mallikarjun C." > >To: > >Cc: > >Sent: Thursday, June 07, 2001 8:04 PM > >Subject: Re: Unsolicited Data. > > > > > >> Steph, > >> > >> I agree with you that mandating unsolicited data to be sent always > >> is limiting, even if InitialR2T=no is negotiated. > >> > >> I suggest the following for consideration - > >> - If the command F-bit is set: > >> - if immediate data is present, it's all the data > >> for the command. (as in rev06) > >> - if immediate data is not present, there are no > >> unsolicited data PDUs following. > >> - If the command F-bit is not set: > >> - if immediate is present, there is more solicited > >> data to follow. > >> - if immediate data is not present, there may be > >> solicited data depending on "Expected Data Transfer > >> Length". > >> > >> The only case this disallows is that of having _both_ unsolicited > >> separate PDUs and immediate data for a command - which I personally > >> am okay with. This is disallowed in rev06 anyway, but for some > >> reason seemed like was changed later. > >> -- > >> Mallikarjun > >> > >> > >> Mallikarjun Chadalapaka > >> Networked Storage Architecture > >> Network Storage Solutions Organization > >> MS 5668 Hewlett-Packard, Roseville. > >> cbm@rose.hp.com > >> > >> > > >> >Sanjeev, > >> > > >> >> why would initiator choose not to send unsolicited immediate data when > >> >> it has negotiated for IntialR2T= Yes?? > >> > > >> >I assume you mean InitialR2T=no. > >> > > >> >I would do this because I think that the real benefit of unsolicited > >> >data is for writes where ALL the write data can be sent unsolicited, > >> >and I'm happy to have the target schedule the transfer of (ALL) data > >> >for larger writes. Of course, others would say I'm a moron. > >> > > >> >Assuming the overwhelming majority of storage use is file access, > >> >small writes are exclusively file system metadata writes. Unsolicited > >> >data is a huge win for metadata writes because the latency of these > >> >metadata writes is frequently not covered by transferring other data > >> >(within a single access thread). On the other hand, the file system > >> >(usually) generates enough concurrent demand for real data writes that > >> >the flow control (R2T) latency is well hidden. > >> > > >> >You might argue that if you're running a file system optimized fors > >> >today's SANs over a link with a HUGE bandwidth * delay product > >> >(greater than the expected demand created by the file system), sending > >> >large amounts of unsolicited write data will substantially improve the > >> >link utilization. That is true, but I don't think many targets are > >> >going to offer unsolicited data bursts remotely that large. > >> > > >> >In a hardware accelerate implementation, unsolicited data will be > >> >handled differently than solicited data. The target can chose where > >> >the solicited data is delivered, but unsolicited data arrives through > >> >a general-delivery path. Therefore, if the offered unsolicited data > >> >burst size approaches the regular burst size, an implementation will > >> >need TWICE as much buffer memory (half in the general-delivery area > >> >and half in the flow-controlled buffer area) to support the same > >> >operation load. Maybe this tradeoff is OK, but given the cost > >> >sensitivity of storage targets, I doubt it. > >> > > >> >As always, I welcome comments from those who see things differently. > >> > > >> >Steph > >> > > >> > >> > > From owner-ips@ece.cmu.edu Fri Jun 8 13:30:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17698 for ; Fri, 8 Jun 2001 13:30:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58GEx828408 for ips-outgoing; Fri, 8 Jun 2001 12:14:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58Eogg21312 for ; Fri, 8 Jun 2001 10:50:42 -0400 (EDT) Received: from eddylaptop (user-vc8ftn2.biz.mindspring.com [216.135.246.226]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MG0NBS04; Fri, 8 Jun 2001 10:50:35 -0400 Reply-To: From: "Eddy Quicksall" To: Subject: iSCSI: immediate vs. unsolicited Date: Fri, 8 Jun 2001 10:50:25 -0400 Message-ID: <004701c0f02a$5b0857e0$b101a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by ece.cmu.edu id f58GEx928408 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA17698 I see a semantic problem with the use of immediate being a subset of unsolicited. Being a subset, one can't use the word "unsolicited" by itself to mean "without the use of R2T" and some confusion is inevitable. I would like to propose a wording standardization of immediate data vs. unsolicited data. If we could use "immediate data" to mean data accompanying a command PDU and "unsolicited data" meaning data-out PDU’s that are not solicited with an R2T, that would be a great help. If this seems like a good idea, I will be happy to go through and find all references to "immediate" and "unsolicited" and make suggested wording changes. Here is an example: Section: 1.2.5 iSCSI Full Feature Phase Current: Outgoing SCSI data (initiator to target user data or command parameters) is sent as either solicited data or unsolicited data. Solicited data is sent in response to Ready To Transfer (R2T) PDUs. Unsolicited data can be sent as part of an iSCSI command PDU ("immediate data") or in separate iSCSI data PDUs. An initiator may send unsolicited data either as immediate (up to the negotiated maximum PDU size) or in a separate PDU sequence (up to the negotiated limit)). Targets operate in either solicited (R2T) data mode or unsolicited (non R2T) data mode. In unsolicited mode, an initial R2T is implied. A target MAY separately enable immediate data without enabling the more general (separate data PDUs) form of unsolicited data. Proposed: Outgoing SCSI data (initiator to target user data or command parameters) is sent as either immediate data, solicited data or unsolicited data. Immediate data is sent (up to the negotiated maximum PDU size) as part of an iSCSI command PDU ("immediate data"). Unsolicited data is sent in separate iSCSI data PDUs (up to the negotiated limit). Solicited data is sent in response to Ready To Transfer (R2T) PDUs. In unsolicited mode, an initial R2T is implied. A target MAY separately enable immediate data without enabling the unsolicited data. mailto:Eddy@Quicksall.com mailto:Eddy@Quicksall.com From owner-ips@ece.cmu.edu Fri Jun 8 13:30:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17709 for ; Fri, 8 Jun 2001 13:30:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58GUVM29678 for ips-outgoing; Fri, 8 Jun 2001 12:30:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58GUSg29669 for ; Fri, 8 Jun 2001 12:30:28 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 362C01A4 for ; Fri, 8 Jun 2001 18:30:24 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id RAA28106 for ; Fri, 8 Jun 2001 17:30:23 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Fri, 08 Jun 2001 17:30:23 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 17:30:23 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A745@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu Subject: RE: iSCSI: immediate vs. unsolicited Date: Fri, 8 Jun 2001 17:30:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Eddy This certainly gets my vote! Matthew -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, June 08, 2001 3:50 PM To: ips@ece.cmu.edu Subject: iSCSI: immediate vs. unsolicited I see a semantic problem with the use of immediate being a subset of unsolicited. Being a subset, one can't use the word "unsolicited" by itself to mean "without the use of R2T" and some confusion is inevitable. I would like to propose a wording standardization of immediate data vs. unsolicited data. If we could use "immediate data" to mean data accompanying a command PDU and "unsolicited data" meaning data-out PDU's that are not solicited with an R2T, that would be a great help. If this seems like a good idea, I will be happy to go through and find all references to "immediate" and "unsolicited" and make suggested wording changes. Here is an example: Section: 1.2.5 iSCSI Full Feature Phase Current: Outgoing SCSI data (initiator to target user data or command parameters) is sent as either solicited data or unsolicited data. Solicited data is sent in response to Ready To Transfer (R2T) PDUs. Unsolicited data can be sent as part of an iSCSI command PDU ("immediate data") or in separate iSCSI data PDUs. An initiator may send unsolicited data either as immediate (up to the negotiated maximum PDU size) or in a separate PDU sequence (up to the negotiated limit)). Targets operate in either solicited (R2T) data mode or unsolicited (non R2T) data mode. In unsolicited mode, an initial R2T is implied. A target MAY separately enable immediate data without enabling the more general (separate data PDUs) form of unsolicited data. Proposed: Outgoing SCSI data (initiator to target user data or command parameters) is sent as either immediate data, solicited data or unsolicited data. Immediate data is sent (up to the negotiated maximum PDU size) as part of an iSCSI command PDU ("immediate data"). Unsolicited data is sent in separate iSCSI data PDUs (up to the negotiated limit). Solicited data is sent in response to Ready To Transfer (R2T) PDUs. In unsolicited mode, an initial R2T is implied. A target MAY separately enable immediate data without enabling the unsolicited data. mailto:Eddy@Quicksall.com mailto:Eddy@Quicksall.com From owner-ips@ece.cmu.edu Fri Jun 8 13:31:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17742 for ; Fri, 8 Jun 2001 13:31:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58FA3E23568 for ips-outgoing; Fri, 8 Jun 2001 11:10:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58FA1g23564 for ; Fri, 8 Jun 2001 11:10:02 -0400 (EDT) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel2.hp.com (Postfix) with ESMTP id 277DE1F22 for ; Fri, 8 Jun 2001 08:09:59 -0700 (PDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 19A291F5B5 for ; Fri, 8 Jun 2001 08:07:16 -0700 (PDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 11:08:54 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A090E0@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI: IP fragmentation Date: Fri, 8 Jun 2001 11:08:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mandating special behavior between the IP stack and the TCP stack is outside the scope of the IPS charter. However, a TCP stack that implements PMTU discovery already sets the DF bit in IP packets. It seems reasonable to state recommendations regarding the RFCs implemented by the TCP stack that iSCSI is running on top of, like "the TCP stack SHOULD support RFC 1191, " Implementors should also be aware of RFC 1435 and RFC 2923. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Joshua Tseng [mailto:jtseng@NishanSystems.com] > Sent: Thursday, June 07, 2001 6:10 PM > To: ips@ece.cmu.edu > Subject: iSCSI: IP fragmentation > > > Folks, > > IP fragmentation is an issue which will affect the > performance, logic and > HBA/NIC memory requirements of iSCSI > implementations. Note > that > fragmentation by intermediary switches and > routers is not > permitted > in IPv6 (hence, the DO NOT FRAGMENT bit does > not exist in > IPv6). > With this in mind, and in the interest of > optimizing iSCSI > performance, > I was wondering if it would make sense to > require that the > DO NOT FRAGMENT bit to be set on IPv4 packets > carrying iSCSI > and > that iSCSI implementations not perform IP > fragmentation for > IPv6. > This will allow for performance optimization if > implementations do not > have to check for fragmentation and handle reassembly. > > Any thoughts? > > Josh > From owner-ips@ece.cmu.edu Fri Jun 8 13:33:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17793 for ; Fri, 8 Jun 2001 13:33:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58GF7428418 for ips-outgoing; Fri, 8 Jun 2001 12:15:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58Eomg21431 for ; Fri, 8 Jun 2001 10:50:48 -0400 (EDT) Received: from eddylaptop (user-vc8ftn2.biz.mindspring.com [216.135.246.226]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MG0NBS0W; Fri, 8 Jun 2001 10:50:41 -0400 Reply-To: From: "Eddy Quicksall" To: , Subject: iSCSI: 0 length data segments Date: Thu, 7 Jun 2001 20:16:57 -0400 Message-ID: <004801c0f02a$5ee061f0$b101a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C0F008.D7CEC1F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C0F008.D7CEC1F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Julian, I don't think the spec should say "sending of 0 length data segments should be avoided". There is no boundary condition. An example of 0 being allowed (where they could have said to avoid it) is in a SCSI READ CDB. Eddy ------=_NextPart_000_0049_01C0F008.D7CEC1F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Julian, I don't think the = spec should say=20 "sending of 0 length data segments should be avoided". There is no = boundary=20 condition. An example of 0 being allowed (where they could have said to = avoid=20 it) is in a SCSI READ CDB.

Eddy
 
------=_NextPart_000_0049_01C0F008.D7CEC1F0-- From owner-ips@ece.cmu.edu Fri Jun 8 13:34:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17816 for ; Fri, 8 Jun 2001 13:34:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58G9ax27943 for ips-outgoing; Fri, 8 Jun 2001 12:09:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58G9Zg27939 for ; Fri, 8 Jun 2001 12:09:35 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA07255; Fri, 8 Jun 2001 12:09:27 -0400 (EDT) Message-ID: <3B20F7DD.4A8C6A7A@cisco.com> Date: Fri, 08 Jun 2001 11:05:49 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Matt Wakeley CC: ips@ece.cmu.edu Subject: Re: iSCSI: Logout command, or The Initiator's new close() References: <3B1D7D4B.110FEC92@agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- I agree with Matt; since I haven't seen any disagreement with this option, can we dicate it in 07? -- Mark Matt Wakeley wrote: > > I think we must dictate implementation. Anything other than specifying how > the close is to work mean interoperability problems. I vote for Mark's first > choice: > > > The most straight-forward choice might be: > > > > Initiator sends the logout request, and simply waits for > > the response without closing the connection. The target > > sends the logout response, and closes its end of the > > connection. The initiator receives the logout response, > > and the FIN from the target, and closes its end of the > > connection. > > That way, if there are outstanding I/Os that need to be completed or errors > that must be communicated, the appropriate communication can be completed > before the TCP connections are destroyed. > > -Matt Wakeley > Agilent Technologies > > julian_satran@il.ibm.com wrote: > > > > Mark, > > > > I don't think that we should dictate implementation. > > As we assume that nothing is sent after Logout (should we spell this out) > > and we have to wait > > for the logout response we can do a half close and wait or wait and do a > > full close after seeing the Logout response. > > The first is faster the second is simpler. > > > > Regards, > > Julo > > > > Mark Bakke on 26-05-2001 00:43:30 > > > > Please respond to Mark Bakke > > > > To: IPS > > cc: > > Subject: iSCSI: Logout command, or The Initiator's new close() > > > > Section 2.14 (the logout command) is not clear on how the logout > > command and response work when the logout request is send on a > > connection for which it requests termination. We should probably > > specify the TCP close behavior of the initiator and target. > > > > The initiator can send the logout request, and either close > > the current connection, half-close the connection and wait > > for the logout response (like HTTP/1.0), or leave it open, > > and close the connection upon receiving the response or the > > FIN from the target. > > > > Upon receiving the logout request, the target can either > > close the connection immediately, send the logout response > > and then close the connection, or send the logout response > > and wait for the initiator to close the connection upon its > > receipt of the logout response. > > > > Logout would work best if the initiators and targets all did > > this in the same manner, choosing one of the above behaviors > > for the initiator, and a compatible one for the target. > > > > The most straight-forward choice might be: > > > > Initiator sends the logout request, and simply waits for > > the response without closing the connection. The target > > sends the logout response, and closes its end of the > > connection. The initiator receives the logout response, > > and the FIN from the target, and closes its end of the > > connection. > > > > Any opinions on whether this is best? This choice does not > > require the initiator to know that the connection that is being > > closed is the one it sent the logout response on, but does > > require the target to send the logout response before it actually > > closes the connection. > > > > Another behavior that might work would be to say that the target > > closes all of its connections and does cleanup before sending the > > logout response, and if the connection on which the request came > > in is gone, it does not send a response. An initiator whose > > connection is closed after sending the logoout request can assume > > that the request worked. > > > > Anyway, I think that it would be good to clarify this. > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jun 8 18:10:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21176 for ; Fri, 8 Jun 2001 18:10:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58KsZ521955 for ips-outgoing; Fri, 8 Jun 2001 16:54:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailsys01.intnet.net (antares.intnet.net [198.252.32.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58KsYg21950 for ; Fri, 8 Jun 2001 16:54:34 -0400 (EDT) Received: from [207.90.20.22] (HELO borg2) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with SMTP id 9430965 for ips@ece.cmu.edu; Fri, 08 Jun 2001 16:53:35 -0400 Message-ID: <00ef01c0f05d$1cbdcf00$0201a8c0@borg2> From: "Jon William Toigo" To: References: Subject: Standards Docs Date: Fri, 8 Jun 2001 16:53:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am searching for docs related to development efforts in FCIP, iFCP and iSCSI. Found FCIP and iSCSI at the Carnegie Mellon site: (http://www.ece.cmu.edu/~ips/Docs/docs.html) However, the iFCP links do not appear to be working. Anyone know where to get good info on iFCP (and more on FCIP)? I would be most appreciative. Jon William Toigo Independent Consultant and Author jtoigo@intnet.net From owner-ips@ece.cmu.edu Fri Jun 8 18:10:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21187 for ; Fri, 8 Jun 2001 18:10:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58KZ6R20383 for ips-outgoing; Fri, 8 Jun 2001 16:35:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58KZ5g20379 for ; Fri, 8 Jun 2001 16:35:05 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA16129 for ; Fri, 8 Jun 2001 16:34:55 -0400 (EDT) Message-ID: <3B213614.B8345D95@cisco.com> Date: Fri, 08 Jun 2001 15:31:16 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: Wrapping up SendTargets Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dear Discovery Enthusiasts- The SendTargets threads are winding down, so I would like to see if we have a rough consensus on a few things. I've read through all of the threads on whether to keep SendTargets in iSCSI, and I believe there is a rough concensus that we should keep it in, carefully limit its growth, and recommend that functionality beyond the basic reporting of the targets and addresses available be implemented using standard discovery protocols instead. On looking through responses from Josh, Steph, Larry, Paul, Julian, Mallikarjun, John, Kaladhar, Jim, and Marjorie, I have seen 7 (I include myself in this count) in favor of keeping SendTargets but limiting its growth, one in favor of dropping SendTargets, and three with no comment on SendTargets. For adding discovery functionality beyond basic reporting of available targets and addresses, I have seen 5 (again, including myself) in favor of using SLP for future discovery, one in favor of using iSNS for future discovery, two in favor of either SLP or iSNS, and three with no comment. I realize that this doesn't constitute calling consensus, and I'm not the person to do it, but I wanted to point out where most people who have responded seem to be headed, so that others who wish to be heard are motivated to comment. Anyway, that said, I would like to see SendTargets stay in the draft, mainly for the same reasons that several others already stated: SendTargets shares the same authentication as iSCSI. SendTargets provides a simple, low-risk path to building interoperable, minimal-configuration iSCSI implementations. SendTargets builds on the existing iSCSI login and text commands, and will be the smallest-footprint and -effort way to implement this basic functionality. The first reason given above is the most important. I believe that we should limit extensions to it as much as possible, for instance, we should not attempt to return certificates and other information. Implementations that wish to do fancier things like these would implement one of the other discovery mechanisms. We could go as far as atrophying SendTargets later, but I think that John is right, that it would be a decision to be made later (iSCSIv2). That said, I do agree that Julian is correct from a philosophical point of view; discovery really belongs outside the protocol. This is a direction we need to pursue. I absolutely agree with Julian that we have to be careful not to let something like SendTargets turn into a management protocol. It would be "easy to do" :-). I see a mild consensus toward SLP as a good direction for moving forward with discovery beyond simple target reporting. The SLP folks themselves intended for hosts to be able to behave in the Unicast manner we are trying, and are interested in updating the SLP API to handle this. However, I think that it would be best to use SendTargets for now, while we both make sure that the right SLP API is developed, and that we can solve the problem of authentication schemes. On ReportPortalGroups I did not hear anyone say we didn't need this functionality; most seemed to say the we either "at least" need ReportPortalGroups if we don't have SendTargets, or that SendTargets was assumed, and ReportPortalGroups is a subset. I agree that this is necessary functionality, but that if we can assume that we still have SendTargets, ReportPortalGroups is really a subset. Paul mentioned just using: SendTargets would be the same as ReportPortalGroups. This might help avoid the feature creep that some of the responders feared. Anyway, either way of doing ReportPortalGroups (making it its own command or making it part of SendTargets) is fine with me. I think that the consensus was that as long as we have SendTargets, we should use it for the ReportPortalGroups functionality. On the Growth of SendTargets A few people mentioned concern about TargetAlias and digital certificates. TargetAlias is returned by the target upon login anyway, so I could live with removing it from SendTargets, and letting the higher-level discovery/management mechanisms deal with it. I think that the same goes for certificates. As we figure out how our customers really want to do security for iSCSI, we may have other mechanisms in place for handling these. This should help keep SendTargets from growing. Stating that it is limited to name, address, and aggregation information (just what is required to connect) should keep it right where it is, and the future discovery mechanisms can take over from there. So here's what I think we have: Now - Keep SendTargets, document it in the iSCSI spec, and declare its limitation to just what is needed to connect to a target (name, address, aggregation). Define ReportPortalGroups functionality as a subset of SendTargets. Future - Pursue SLP as the "standard discovery", allowing for other solutions such as iSNS as appropriate. Do we have rough consensus on either of the above, at least on the "Now" part? Once we have consensus on that, we can continue the threads on aggregation tags, which targets should provide SendTargets, and whether or not we need iterators. Anyway, I have to apologize in advance; I will be out of the office until the 18th, so I am sort of throwing this out on the list and running away. Regards, -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jun 8 18:49:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21398 for ; Fri, 8 Jun 2001 18:49:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58KR1n19830 for ips-outgoing; Fri, 8 Jun 2001 16:27:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58KQxg19825 for ; Fri, 8 Jun 2001 16:27:00 -0400 (EDT) Received: from HQMailWeb.Crossroads.com [63.237.99.250:25] by va2mc.ummailbox.net with SMTP id A0608-1626-01af00; Fri, 8 Jun 2001 20:26:53 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 8 Jun 2001 15:26:52 -0500 content-class: urn:content-classes:message Subject: RE: iSCSI: text commands that set mode parameters MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 8 Jun 2001 15:26:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: Thread-Topic: iSCSI: text commands that set mode parameters Thread-Index: AcDvmR/+cEg9zsEGR/mgpJlLYDYGcAAvs90Q From: "Robert Griswold" To: Cc: X-OriginalArrivalTime: 08 Jun 2001 20:26:52.0190 (UTC) FILETIME=[5A2B0BE0:01C0F059] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f58KR0g19826 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Eddy: I have found a couple of threads on this subject, and it seems that quite a few others involved in T10 work agree with you on the fact that mode page or setting manipulation outside of the mode commands is not in-line with the scope of the iSCSI mapping. I see that iSCSI needs to be able to manipulate items such as Disconnect/Reconnect and BurstSize, but if those settings live in Mode Pages, then iSCSI needs to use mode commands to get or change them, right? These threads discuss mode pages, but I am not sure I see any resolution to this redundancy yet. Can anyone tell me if there was a final decision to modify the mode page language Eddy refers to? http://ips.pdl.cs.cmu.edu/mail/msg04176.html http://ips.pdl.cs.cmu.edu/mail/msg03519.html Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Thursday, June 07, 2001 4:06 PM To: ips@ece.cmu.edu Subject: iSCSI: text commands that set mode parameters I'm not crazy about setting mode parameters from text commands because the mode pages are in logic which is outside of iSCSI. Section 3 - SCSI Mode Parameters for iSCSI says: The mode parameters can be set and retrieved by SCSI mode-set and mode-sense commands or with the iSCSI text commands and responses. The text commands offer the added convenience that at the end of the exchange the value selected is known to both parties. I agree with the spirit of the last sentence above but I still think the logic is misplaced. Has anyone debated this yet? Does anyone else share my opinion? Is there a good reason to have the iSCSI layer do this? Can we talk about this or is there a thread I should review? Eddy From owner-ips@ece.cmu.edu Fri Jun 8 19:38:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21842 for ; Fri, 8 Jun 2001 19:38:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58Lv1426338 for ips-outgoing; Fri, 8 Jun 2001 17:57:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58Luxg26331 for ; Fri, 8 Jun 2001 17:56:59 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f58LuVE15910 for ; Fri, 8 Jun 2001 17:56:32 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Fri, 8 Jun 2001 17:56:14 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MLGL5DV2; Fri, 8 Jun 2001 17:55:58 -0400 Received: from travos.nortelnetworks.com (dhcp223-133.engeast.baynetworks.com [192.32.223.133]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JPBDMCX4; Fri, 8 Jun 2001 17:56:10 -0400 Message-Id: <5.0.2.1.2.20010608175632.03b92590@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 08 Jun 2001 18:07:06 -0400 To: Jon William Toigo , ips From: "Franco Travostino" Subject: Re: Standards Docs In-Reply-To: <00ef01c0f05d$1cbdcf00$0201a8c0@borg2> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_30427304==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_30427304==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed The link in the CMU page happens to be off by one revision number for the iFCP I-D. It links to http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-01.txt whereas the current iFCP draft is at http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-02.txt I will ask the webmaster to update it. Note that the official IETF IPS WG home page is accurate (http://www.ietf.org/html.charters/ips-charter.html). -franco At 04:53 PM 6/8/2001, Jon William Toigo wrote: >I am searching for docs related to development efforts in FCIP, iFCP and >iSCSI. Found FCIP and iSCSI at the Carnegie Mellon site: > >(http://www.ece.cmu.edu/~ips/Docs/docs.html) > >However, the iFCP links do not appear to be working. Anyone know where to >get good info on iFCP (and more on FCIP)? > >I would be most appreciative. > >Jon William Toigo >Independent Consultant and Author >jtoigo@intnet.net Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com --=====================_30427304==_.ALT Content-Type: text/html; charset="us-ascii"
The link in the CMU page happens to be off by one revision number for the iFCP I-D.
It links to http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-01.txt
whereas the current iFCP draft is at http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-02.txt
I will ask the webmaster to update it.

Note that the official IETF IPS WG home page is accurate (http://www.ietf.org/html.charters/ips-charter.html).

-franco

At 04:53 PM 6/8/2001, Jon William Toigo wrote:
I am searching for docs related to development efforts in FCIP, iFCP and
iSCSI.  Found FCIP and iSCSI at the Carnegie Mellon site:

(http://www.ece.cmu.edu/~ips/Docs/docs.html)

However, the iFCP links do not appear to be working.  Anyone know where to
get good info on iFCP (and more on FCIP)?

I would be most appreciative.

Jon William Toigo
Independent Consultant and Author
jtoigo@intnet.net


Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
 --=====================_30427304==_.ALT-- From owner-ips@ece.cmu.edu Fri Jun 8 19:39:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21853 for ; Fri, 8 Jun 2001 19:39:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58Lv2A26342 for ips-outgoing; Fri, 8 Jun 2001 17:57:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58Lv0g26337 for ; Fri, 8 Jun 2001 17:57:00 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA41266 for ; Fri, 8 Jun 2001 16:51:29 -0500 Received: from f4n49e (d03nm065h.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f58LthE76686 for ; Fri, 8 Jun 2001 15:55:43 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Wrapping up SendTargets To: IPS X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 8 Jun 2001 14:55:31 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/08/2001 03:55:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I agree with Mark's statements: " Now - Keep SendTargets, document it in the iSCSI spec, and declare its limitation to just what is needed to connect to a target (name, address, aggregation). Define ReportPortalGroups functionality as a subset of SendTargets. Future - Pursue SLP as the "standard discovery", allowing for other solutions such as iSNS as appropriate." especially since most folks that bothered to respond did not like my compromise of an Annex. The only important point, from my standpoint is: if SendTargets goes away for any reason, we still need the ReportPortalGroups function. So if we use the suggested syntax of "SendTargets " instead of ReportPortalGroups, we need to find a way to protect the subset function that is "ReportPortalGroups", so it never goes away even if SendTargets does. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com Mark Bakke @ece.cmu.edu on 06/08/2001 01:31:16 PM Sent by: owner-ips@ece.cmu.edu To: IPS cc: Subject: iSCSI: Wrapping up SendTargets Dear Discovery Enthusiasts- The SendTargets threads are winding down, so I would like to see if we have a rough consensus on a few things. I've read through all of the threads on whether to keep SendTargets in iSCSI, and I believe there is a rough concensus that we should keep it in, carefully limit its growth, and recommend that functionality beyond the basic reporting of the targets and addresses available be implemented using standard discovery protocols instead. On looking through responses from Josh, Steph, Larry, Paul, Julian, Mallikarjun, John, Kaladhar, Jim, and Marjorie, I have seen 7 (I include myself in this count) in favor of keeping SendTargets but limiting its growth, one in favor of dropping SendTargets, and three with no comment on SendTargets. For adding discovery functionality beyond basic reporting of available targets and addresses, I have seen 5 (again, including myself) in favor of using SLP for future discovery, one in favor of using iSNS for future discovery, two in favor of either SLP or iSNS, and three with no comment. I realize that this doesn't constitute calling consensus, and I'm not the person to do it, but I wanted to point out where most people who have responded seem to be headed, so that others who wish to be heard are motivated to comment. Anyway, that said, I would like to see SendTargets stay in the draft, mainly for the same reasons that several others already stated: SendTargets shares the same authentication as iSCSI. SendTargets provides a simple, low-risk path to building interoperable, minimal-configuration iSCSI implementations. SendTargets builds on the existing iSCSI login and text commands, and will be the smallest-footprint and -effort way to implement this basic functionality. The first reason given above is the most important. I believe that we should limit extensions to it as much as possible, for instance, we should not attempt to return certificates and other information. Implementations that wish to do fancier things like these would implement one of the other discovery mechanisms. We could go as far as atrophying SendTargets later, but I think that John is right, that it would be a decision to be made later (iSCSIv2). That said, I do agree that Julian is correct from a philosophical point of view; discovery really belongs outside the protocol. This is a direction we need to pursue. I absolutely agree with Julian that we have to be careful not to let something like SendTargets turn into a management protocol. It would be "easy to do" :-). I see a mild consensus toward SLP as a good direction for moving forward with discovery beyond simple target reporting. The SLP folks themselves intended for hosts to be able to behave in the Unicast manner we are trying, and are interested in updating the SLP API to handle this. However, I think that it would be best to use SendTargets for now, while we both make sure that the right SLP API is developed, and that we can solve the problem of authentication schemes. On ReportPortalGroups I did not hear anyone say we didn't need this functionality; most seemed to say the we either "at least" need ReportPortalGroups if we don't have SendTargets, or that SendTargets was assumed, and ReportPortalGroups is a subset. I agree that this is necessary functionality, but that if we can assume that we still have SendTargets, ReportPortalGroups is really a subset. Paul mentioned just using: SendTargets would be the same as ReportPortalGroups. This might help avoid the feature creep that some of the responders feared. Anyway, either way of doing ReportPortalGroups (making it its own command or making it part of SendTargets) is fine with me. I think that the consensus was that as long as we have SendTargets, we should use it for the ReportPortalGroups functionality. On the Growth of SendTargets A few people mentioned concern about TargetAlias and digital certificates. TargetAlias is returned by the target upon login anyway, so I could live with removing it from SendTargets, and letting the higher-level discovery/management mechanisms deal with it. I think that the same goes for certificates. As we figure out how our customers really want to do security for iSCSI, we may have other mechanisms in place for handling these. This should help keep SendTargets from growing. Stating that it is limited to name, address, and aggregation information (just what is required to connect) should keep it right where it is, and the future discovery mechanisms can take over from there. So here's what I think we have: Now - Keep SendTargets, document it in the iSCSI spec, and declare its limitation to just what is needed to connect to a target (name, address, aggregation). Define ReportPortalGroups functionality as a subset of SendTargets. Future - Pursue SLP as the "standard discovery", allowing for other solutions such as iSNS as appropriate. Do we have rough consensus on either of the above, at least on the "Now" part? Once we have consensus on that, we can continue the threads on aggregation tags, which targets should provide SendTargets, and whether or not we need iterators. Anyway, I have to apologize in advance; I will be out of the office until the 18th, so I am sort of throwing this out on the list and running away. Regards, -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jun 8 19:40:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21871 for ; Fri, 8 Jun 2001 19:40:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58MPsG28213 for ips-outgoing; Fri, 8 Jun 2001 18:25:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com (sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58MPqg28204 for ; Fri, 8 Jun 2001 18:25:52 -0400 (EDT) Received: from cs.uchicago.edu (dynamite-46.sandburst.com [172.16.5.46]) by sandmail.sandburst.com (Postfix) with ESMTP id 9BDCA94010; Fri, 8 Jun 2001 18:25:48 -0400 (EDT) To: end2end-interest@postel.org, tsvwg@ietf.org, ips@ece.cmu.edu, rdma@yahoogroups.com Subject: I-D ACTION:draft-pinkerton-rdma-reqmts-00.txt Date: Fri, 08 Jun 2001 18:23:33 -0400 From: Stephen Bailey Message-Id: <20010608222548.9BDCA94010@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk The following Internet Draft may be of interest to this mailing list. General discussion of this draft should take place on the RDMA mailing list, rdma@yahoogroups.com (or http://groups.yahoo.com/group/rdma). Steph ____________________________________________________________________ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for an RDMA Protocol Author(s) : J. Pinkerton, M. Krause, S. Bailey Filename : draft-pinkerton-rdma-reqmts-00.txt Pages : 10 Date : 04-Jun-01 This document proposes requirements for a Remote Direct Memory Access (RDMA) Protocol to run on TCP and SCTP transport protocols. An RDMA protocol provides a general facility for extremely high efficiency (low CPU cost per unit of data transferred), end-to-end data transfer. An RDMA protocol enables high efficiency data transfer by allowing network interfaces with hardware support for the RDMA protocol to perform zero-copy data transfer directly among application buffers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pinkerton-rdma-reqmts-00.txt 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-pinkerton-rdma-reqmts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pinkerton-rdma-reqmts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ips@ece.cmu.edu Fri Jun 8 19:40:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21883 for ; Fri, 8 Jun 2001 19:40:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58M3MD26730 for ips-outgoing; Fri, 8 Jun 2001 18:03:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58M3Kg26711 for ; Fri, 8 Jun 2001 18:03:20 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 15:03:14 -0700 Message-ID: From: Charles Monia To: "'Jon William Toigo'" Cc: "Ips (E-mail)" Subject: RE: Standards Docs Date: Fri, 8 Jun 2001 15:03:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Jon: Try: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-02.txt Charles > -----Original Message----- > From: Jon William Toigo [mailto:jtoigo@IntNet.net] > Sent: Friday, June 08, 2001 1:54 PM > To: ips@ece.cmu.edu > Subject: Standards Docs > > > I am searching for docs related to development efforts in > FCIP, iFCP and > iSCSI. Found FCIP and iSCSI at the Carnegie Mellon site: > > (http://www.ece.cmu.edu/~ips/Docs/docs.html) > > However, the iFCP links do not appear to be working. Anyone > know where to > get good info on iFCP (and more on FCIP)? > > I would be most appreciative. > > Jon William Toigo > Independent Consultant and Author > jtoigo@intnet.net > > From owner-ips@ece.cmu.edu Fri Jun 8 20:51:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22481 for ; Fri, 8 Jun 2001 20:51:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f58NDWh01326 for ips-outgoing; Fri, 8 Jun 2001 19:13:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f58NDVg01322 for ; Fri, 8 Jun 2001 19:13:31 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 16:13:25 -0700 Message-ID: From: Joshua Tseng To: "'Kaladhar Voruganti'" , ips@ece.cmu.edu Subject: RE: iSCSI: Send Targets and Report Portal Groups Date: Fri, 8 Jun 2001 16:13:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Kal, I agree with you in supporting John's compromise. Sendtargets should be documented SOMEWHERE, since many have already implemented it. In addition, I believe a lightweight discovery mechanism would be useful in the short term until iSNS and SLP integration issues are "shaken out". Therefore, I believe an annex would be a convenient place to document Sendtargets until the other discovery mechanisms can move forward. Josh > -----Original Message----- > From: Kaladhar Voruganti [mailto:kaladhar@us.ibm.com] > Sent: Thursday, June 07, 2001 1:31 PM > To: ips@ece.cmu.edu > Subject: iSCSI: Send Targets and Report Portal Groups > > > John, > I am supporting your solution because it is a compromise, and > there are > many who are already using the SendTarget discovery method. > > Reasons for having it (others can add to this list): > 1) Already many implementations are using it. > 2) Purists will argue that it is a simple discovery method and not a > management mechanism. > 3 ) Can use the same Login and authentication mechanism as iSCSI. > 4) iSCSI will not be the first protocol to have an in-band discovery > mechanism (Report_Luns in SCSI). > 5) Simple implementations will not have to use SLP or iSNS. > > Reasons for not having it (others can add to this list): > 1) Do not want discovery mechanism as part of the protocol. > 2) It will continue to evolve and is not as simple as it seems. > 3) IETF standards approving body will have a problem with it, > and this will > delay the approval of the whole standard. > 4) Can use SLP or iSNS to get the same functionality, and we > can piggyback > on the future enhancements to these discovery protocols. > > If we do keep the SendTarget command, then I want the > following two points > clarified: > > 1) If we keep SendTargets in version 1 annex, will it still > be optional to > implement? > 2) What is the impact (if any) of passing digital > certificates with the > SendTarget response? > > I also agree that there is a need for a Report Portal Groups type of > command. I will let people argue whether it is a separate > issue than the > SendTargets command. > > Kaladhar > > > > > > > ---------------------- Forwarded by Kaladhar Voruganti/Almaden/IBM on > 06/07/2001 12:59 PM --------------------------- > > John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 06/06/2001 07:34:01 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI: Send Targets and Report Portal Groups > > > > iSCSI Team, > I would like to propose the following approaches to address > the issues of > Send-Targets, and Report Portal Groups. > > The way Send-Targets has evolved, which is now a separate > interaction with > its own Login, makes it seem like the same function can be rationally > performed by current Discovery Functions in SLP or iSNS. Now > this is not > completely correct, but close enough for me to propose a compromise. > Before I state the compromise let me address the items that > are current > concerns with an SLP or iSNS approach of replacing Send-Targets. > > 1. The current SLP Open Source does not do a Unicast to ask for the > information. This is not a shortcoming of the SLP protocol, just the > current API/Implementation. Mark Bakke has made a Hack into the Open > Source and believes that it will work just fine, and also > thinks he has > support for that approach from the Owners of the Open Source. > However, > there is still some uncertainty here, which will only be > cleared up with > time and multiple implementations. > 2. There are separate Authentication models followed by > SLP/iSNS as opposed > to iSCSI. Therefore, any Initiator attempting to do SLP or > iSNS for basic > discovery, needs to address two Authentication models, the discovery > method's authentication approach, and iSCSI's. > 3. In small installations it is not clear that there will be > an SLP or iSNS > setup on which to leverage this approach. > > Now, I am cretin there will be arguments about the > importance of any of > those points, the issue is -- the uncertainty of favorable results. > > I am of the belief that it maybe worth the effort to move in > the direction > of "atrophying" the Send Targets Command and Processes. That > is, it serves > a current and valuable function, of which a favorable > replacement, though > probable, is uncertain at this time. So we should begin moving in the > direction of the SLP/iSNS approach, but without additional > care and feeding > of Send Targets. An approach to this is to move the Send > Target Command > and Processes, into an Annex of the main iSCSI protocol > document. As such > it will be a current requirement for implementation, but it > will also be > clear that we believe it may be eliminated in version 2 of the iSCSI > document (when ever that occurs) and is not something in which feature > creep will be permitted. > > I think the above approach will satisfy the folks that have > been building > and testing various product approaches that depend on Send > Targets, and yet > give them time to move to an SLP or iSNS type approach as the concerns > specified above are worked out. > > It is also possible that in the future, we will find that we are > fundamentally wrong in some of our key assumptions, and that > Version 2 may > move it back into the main document. That would also be acceptable, > because I do not believe it would happen lightly, and would > have to have > great reasoning and logic behind such a move. > > Now, I would like to address the Report Portal Groups. I do > not place this > in the same category as Send Targets. It is a specific query > about the > environment of the specific session in which the command is > issued. It is > analogous to Report LUNs, and querying Mode Pages. > > For those of you that have not been following this closely, the Report > Portal Groups, is a command that responds with the IP > addresses that can be > used by the initiator of the current session, to add > additional connections > to the current session (and thereby support Multiple Connections per > Session). > > It is specific to its own session, and not to some general > management item. > Some might say that this too could be discovered by some management > function, however, that could also be true about many of the Mode Page > setting also. In my opinion the Portal Groups will probably > be "wired in" > by the Storage Controller vendor and not be something that is > settable by > the administrator. In fact with Report Portal Groups, being > part of the > base protocol, the SLP/iSNS (or the Send Targets Command) > will not have to > include the portal group identification/tagging in its responses, thus > simplifying them. > > So as part of my proposed compromise I recommend that we put > "Report Portal > Groups" into the main iSCSI Protocol Document, like any of > the other iSCSI > Commands, and move the Send-Targets command to an Annex as > specified above. > > > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Internet address: hufferd@us.ibm.com > > > > From owner-ips@ece.cmu.edu Fri Jun 8 22:08:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23930 for ; Fri, 8 Jun 2001 22:08:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f590MPf05852 for ips-outgoing; Fri, 8 Jun 2001 20:22:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f590MOg05848 for ; Fri, 8 Jun 2001 20:22:24 -0400 (EDT) Received: (cpmta 7338 invoked from network); 8 Jun 2001 17:22:18 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.206) with SMTP; 8 Jun 2001 17:22:18 -0700 X-Sent: 9 Jun 2001 00:22:18 GMT From: "Douglas Otis" To: , , , Subject: RE: [rdma] I-D ACTION:draft-pinkerton-rdma-reqmts-00.txt Date: Fri, 8 Jun 2001 17:20:00 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <20010608222548.9BDCA94010@sandmail.sandburst.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stephen, Good to see error handling was changed to hit it with a hammer or hit it with a bigger hammer. My concern is about the fragility such a scheme would have. Doug From owner-ips@ece.cmu.edu Fri Jun 8 23:04:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25201 for ; Fri, 8 Jun 2001 23:04:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f591sB411120 for ips-outgoing; Fri, 8 Jun 2001 21:54:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nic-naa.net (216-220-241-232.midmaine.com [216.220.241.232]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f590DOg05310 for ; Fri, 8 Jun 2001 20:13:24 -0400 (EDT) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.3/8.9.3) with ESMTP id f590Bjr64551; Fri, 8 Jun 2001 20:11:45 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200106090011.f590Bjr64551@nic-naa.net> To: Stephen Bailey cc: end2end-interest@postel.org, tsvwg@ietf.org, ips@ece.cmu.edu, rdma@yahoogroups.com, brunner@nic-naa.net Subject: Re: [e2e] I-D ACTION:draft-pinkerton-rdma-reqmts-00.txt In-Reply-To: Your message of "Fri, 08 Jun 2001 18:23:33 EDT." <20010608222548.9BDCA94010@sandmail.sandburst.com> Date: Fri, 08 Jun 2001 20:11:45 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-ips@ece.cmu.edu Precedence: bulk > General discussion of this draft should take place on the RDMA mailing > list, rdma@yahoogroups.com (or http://groups.yahoo.com/group/rdma). This isn't a venue that is particularly attractive, yahoo costs several set-cookie events for every page view. From owner-ips@ece.cmu.edu Fri Jun 8 23:05:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25212 for ; Fri, 8 Jun 2001 23:05:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f591Q9t09594 for ips-outgoing; Fri, 8 Jun 2001 21:26:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f591Q7g09589 for ; Fri, 8 Jun 2001 21:26:08 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 18:26:02 -0700 Message-ID: From: Joshua Tseng To: "'Mark Bakke'" , IPS Subject: RE: iSCSI: Wrapping up SendTargets Date: Fri, 8 Jun 2001 18:26:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, > For adding discovery functionality beyond basic reporting > of available targets and addresses, I have seen 5 > (again, including myself) in favor of using SLP for > future discovery, one in favor of using iSNS for future > discovery, two in favor of either SLP or iSNS, and > three with no comment. > > I realize that this doesn't constitute calling consensus, > and I'm not the person to do it, but I wanted to point out > where most people who have responded seem to be headed, > so that others who wish to be heard are motivated to > comment. Am I missing something here? I had thought the previous discussions on this thread were regarding use of Sendtargets, not a referendum on SLP or iSNS. I am still waiting for a technical response to my previous messages over the last two months regarding iSNS and SLP. SLP lacks essential capabilities that iSNS provides, and no one has been able to explain how they will provide them with SLP or any other protocol. How can you possibly say we are headed in the direction of SLP when its technical issues as far as addressing storage discovery issues have not been resolved? > I see a mild consensus toward SLP as a good direction for > moving forward with discovery beyond simple target reporting. > The SLP folks themselves intended for hosts to be able to > behave in the Unicast manner we are trying, and are interested > in updating the SLP API to handle this. However, I think that > it would be best to use SendTargets for now, while we both > make sure that the right SLP API is developed, and that we > can solve the problem of authentication schemes. > Before you or anyone calls consensus, I would like to see how SLP can solve the following issues: 1) Management of Discovery Domains. You don't want incompatible file systems discovering each other, or very bad things will happen. Say 'goodbye' to the Unix file system who's host is discovered by SLP.... 2) Transfer of X.509 digital certificates. SLP cannot easily transfer binary entities. This affects the iSCSI target device's ability to enforce its access control list. 3) Monitoring of available devices. SLP relies upon service agents re-registering periodically, in order to keep the freshness of its database entries. But this leads to a dilemma: if SA's re-register too often, the DA will be overwhelmed. And if they register not often enough, then you will have stale device entries. The fact is, SLP was not designed to be a real-time discovery protocol. But in storage networks, real-time information is crucial, as even slightly out-of-date information can lead to unnecessary logins and other events that will seriously degrade the performance of the storage network. 4) State Change Notifications. This is important to support failover and redundancy capabilities, and to ensure that initiators can persistently maintain their sessions with targets in the event of network topology changes. > > Now - Keep SendTargets, document it in the iSCSI spec, and > declare its limitation to just what is needed to > connect to a target (name, address, aggregation). > > Define ReportPortalGroups functionality as a subset > of SendTargets. I understand you'll be out of contact for the next 1.5 weeks, and so you must be in a rush, but I must ask that you give us a at least a few days or so to digest the 10+ messages on this subject. I personally have been in-and-out of the office for the past couple days and haven't been able to respond till now. Once again, I support John's proposal to move Sendtargets to the annex. I don't think Sendtargets should be in the main document. Furthermore, it would be helpful if you clarify whether your statements are representing the iSCSI NDT or only of your personal views. I do not believe your statements regarding the SLP approach for iSCSI are consistent with what was agreed to in the NDT. I believe the consensus was that both iSNS and SLP are to be considered for discovery. > Future - Pursue SLP as the "standard discovery", allowing for > other solutions such as iSNS as appropriate. As an NDT member, I cannot support a decision on making any protocol the "standard" without fully addressing the above technical issues. The devil is in the details, and only after exploring such issues will we be able to avoid future pitfalls that may threaten the timely adoption of iSCSI. Josh > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Friday, June 08, 2001 1:31 PM > To: IPS > Subject: iSCSI: Wrapping up SendTargets > > > > Dear Discovery Enthusiasts- > > The SendTargets threads are winding down, so I would like > to see if we have a rough consensus on a few things. > > > I've read through all of the threads on whether to > keep SendTargets in iSCSI, and I believe there is > a rough concensus that we should keep it in, carefully > limit its growth, and recommend that functionality > beyond the basic reporting of the targets and addresses > available be implemented using standard discovery > protocols instead. On looking through responses from > Josh, Steph, Larry, Paul, Julian, Mallikarjun, John, > Kaladhar, Jim, and Marjorie, I have seen 7 (I include > myself in this count) in favor of keeping SendTargets > but limiting its growth, one in favor of dropping > SendTargets, and three with no comment on SendTargets. > > For adding discovery functionality beyond basic reporting > of available targets and addresses, I have seen 5 > (again, including myself) in favor of using SLP for > future discovery, one in favor of using iSNS for future > discovery, two in favor of either SLP or iSNS, and > three with no comment. > > I realize that this doesn't constitute calling consensus, > and I'm not the person to do it, but I wanted to point out > where most people who have responded seem to be headed, > so that others who wish to be heard are motivated to > comment. > > > Anyway, that said, I would like to see SendTargets stay > in the draft, mainly for the same reasons that several > others already stated: > > SendTargets shares the same authentication as iSCSI. > > SendTargets provides a simple, low-risk path to building > interoperable, minimal-configuration iSCSI implementations. > > SendTargets builds on the existing iSCSI login and text > commands, and will be the smallest-footprint and -effort > way to implement this basic functionality. > > The first reason given above is the most important. > > I believe that we should limit extensions to it as much as > possible, for instance, we should not attempt to return > certificates and other information. Implementations that > wish to do fancier things like these would implement one > of the other discovery mechanisms. We could go as far > as atrophying SendTargets later, but I think that John is > right, that it would be a decision to be made later (iSCSIv2). > > That said, I do agree that Julian is correct from a philosophical > point of view; discovery really belongs outside the protocol. > This is a direction we need to pursue. I absolutely agree with > Julian that we have to be careful not to let something like > SendTargets turn into a management protocol. It would be "easy > to do" :-). > > I see a mild consensus toward SLP as a good direction for > moving forward with discovery beyond simple target reporting. > The SLP folks themselves intended for hosts to be able to > behave in the Unicast manner we are trying, and are interested > in updating the SLP API to handle this. However, I think that > it would be best to use SendTargets for now, while we both > make sure that the right SLP API is developed, and that we > can solve the problem of authentication schemes. > > > On ReportPortalGroups > > I did not hear anyone say we didn't need this functionality; most > seemed to say the we either "at least" need ReportPortalGroups > if we don't have SendTargets, or that SendTargets was assumed, > and ReportPortalGroups is a subset. > > I agree that this is necessary functionality, but that if we > can assume that we still have SendTargets, ReportPortalGroups > is really a subset. Paul mentioned just using: > > SendTargets > > would be the same as ReportPortalGroups. This might help > avoid the feature creep that some of the responders feared. > > Anyway, either way of doing ReportPortalGroups (making it its > own command or making it part of SendTargets) is fine with me. > I think that the consensus was that as long as we have SendTargets, > we should use it for the ReportPortalGroups functionality. > > > On the Growth of SendTargets > > A few people mentioned concern about TargetAlias and digital > certificates. TargetAlias is returned by the target upon login > anyway, so I could live with removing it from SendTargets, and > letting the higher-level discovery/management mechanisms deal > with it. I think that the same goes for certificates. As we > figure out how our customers really want to do security for iSCSI, > we may have other mechanisms in place for handling these. > > This should help keep SendTargets from growing. Stating that > it is limited to name, address, and aggregation information (just > what is required to connect) should keep it right where it is, > and the future discovery mechanisms can take over from there. > > So here's what I think we have: > > Now - Keep SendTargets, document it in the iSCSI spec, and > declare its limitation to just what is needed to > connect to a target (name, address, aggregation). > > Define ReportPortalGroups functionality as a subset > of SendTargets. > > Future - Pursue SLP as the "standard discovery", allowing for > other solutions such as iSNS as appropriate. > > Do we have rough consensus on either of the above, at least > on the "Now" part? > > Once we have consensus on that, we can continue the threads > on aggregation tags, which targets should provide SendTargets, > and whether or not we need iterators. > > Anyway, I have to apologize in advance; I will be out of > the office until the 18th, so I am sort of throwing this out > on the list and running away. > > > Regards, > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Sat Jun 9 03:11:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11760 for ; Sat, 9 Jun 2001 03:11:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f595GhK22540 for ips-outgoing; Sat, 9 Jun 2001 01:16:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f595Ggg22536 for ; Sat, 9 Jun 2001 01:16:42 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id AAA43248 for ; Sat, 9 Jun 2001 00:11:11 -0500 Received: from f4n49e (d03nm065h.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f595FPE80722 for ; Fri, 8 Jun 2001 23:15:25 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Wrapping up SendTargets To: IPS X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 8 Jun 2001 22:15:08 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/08/2001 11:15:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Josha, I failed to notice the exact meaning of the words that Mark used when he said "Future - Pursue SLP as the "standard discovery", allowing for > other solutions such as iSNS as appropriate." I also believe that we agreed to have Both SLP and iSNS be considered for discovery equally. With iSNS being made Open Source, it seems to me that there is little reason to not include it as a full participant, especially since it meets the needs of the larger environments. I also have not seen a reason why it will not work in the medium environments, at least as well as SLP. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com Joshua Tseng @ece.cmu.edu on 06/08/2001 06:26:01 PM Sent by: owner-ips@ece.cmu.edu To: "'Mark Bakke'" , IPS cc: Subject: RE: iSCSI: Wrapping up SendTargets Mark, > For adding discovery functionality beyond basic reporting > of available targets and addresses, I have seen 5 > (again, including myself) in favor of using SLP for > future discovery, one in favor of using iSNS for future > discovery, two in favor of either SLP or iSNS, and > three with no comment. > > I realize that this doesn't constitute calling consensus, > and I'm not the person to do it, but I wanted to point out > where most people who have responded seem to be headed, > so that others who wish to be heard are motivated to > comment. Am I missing something here? I had thought the previous discussions on this thread were regarding use of Sendtargets, not a referendum on SLP or iSNS. I am still waiting for a technical response to my previous messages over the last two months regarding iSNS and SLP. SLP lacks essential capabilities that iSNS provides, and no one has been able to explain how they will provide them with SLP or any other protocol. How can you possibly say we are headed in the direction of SLP when its technical issues as far as addressing storage discovery issues have not been resolved? > I see a mild consensus toward SLP as a good direction for > moving forward with discovery beyond simple target reporting. > The SLP folks themselves intended for hosts to be able to > behave in the Unicast manner we are trying, and are interested > in updating the SLP API to handle this. However, I think that > it would be best to use SendTargets for now, while we both > make sure that the right SLP API is developed, and that we > can solve the problem of authentication schemes. > Before you or anyone calls consensus, I would like to see how SLP can solve the following issues: 1) Management of Discovery Domains. You don't want incompatible file systems discovering each other, or very bad things will happen. Say 'goodbye' to the Unix file system who's host is discovered by SLP.... 2) Transfer of X.509 digital certificates. SLP cannot easily transfer binary entities. This affects the iSCSI target device's ability to enforce its access control list. 3) Monitoring of available devices. SLP relies upon service agents re-registering periodically, in order to keep the freshness of its database entries. But this leads to a dilemma: if SA's re-register too often, the DA will be overwhelmed. And if they register not often enough, then you will have stale device entries. The fact is, SLP was not designed to be a real-time discovery protocol. But in storage networks, real-time information is crucial, as even slightly out-of-date information can lead to unnecessary logins and other events that will seriously degrade the performance of the storage network. 4) State Change Notifications. This is important to support failover and redundancy capabilities, and to ensure that initiators can persistently maintain their sessions with targets in the event of network topology changes. > > Now - Keep SendTargets, document it in the iSCSI spec, and > declare its limitation to just what is needed to > connect to a target (name, address, aggregation). > > Define ReportPortalGroups functionality as a subset > of SendTargets. I understand you'll be out of contact for the next 1.5 weeks, and so you must be in a rush, but I must ask that you give us a at least a few days or so to digest the 10+ messages on this subject. I personally have been in-and-out of the office for the past couple days and haven't been able to respond till now. Once again, I support John's proposal to move Sendtargets to the annex. I don't think Sendtargets should be in the main document. Furthermore, it would be helpful if you clarify whether your statements are representing the iSCSI NDT or only of your personal views. I do not believe your statements regarding the SLP approach for iSCSI are consistent with what was agreed to in the NDT. I believe the consensus was that both iSNS and SLP are to be considered for discovery. > Future - Pursue SLP as the "standard discovery", allowing for > other solutions such as iSNS as appropriate. As an NDT member, I cannot support a decision on making any protocol the "standard" without fully addressing the above technical issues. The devil is in the details, and only after exploring such issues will we be able to avoid future pitfalls that may threaten the timely adoption of iSCSI. Josh > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Friday, June 08, 2001 1:31 PM > To: IPS > Subject: iSCSI: Wrapping up SendTargets > > > > Dear Discovery Enthusiasts- > > The SendTargets threads are winding down, so I would like > to see if we have a rough consensus on a few things. > > > I've read through all of the threads on whether to > keep SendTargets in iSCSI, and I believe there is > a rough concensus that we should keep it in, carefully > limit its growth, and recommend that functionality > beyond the basic reporting of the targets and addresses > available be implemented using standard discovery > protocols instead. On looking through responses from > Josh, Steph, Larry, Paul, Julian, Mallikarjun, John, > Kaladhar, Jim, and Marjorie, I have seen 7 (I include > myself in this count) in favor of keeping SendTargets > but limiting its growth, one in favor of dropping > SendTargets, and three with no comment on SendTargets. > > For adding discovery functionality beyond basic reporting > of available targets and addresses, I have seen 5 > (again, including myself) in favor of using SLP for > future discovery, one in favor of using iSNS for future > discovery, two in favor of either SLP or iSNS, and > three with no comment. > > I realize that this doesn't constitute calling consensus, > and I'm not the person to do it, but I wanted to point out > where most people who have responded seem to be headed, > so that others who wish to be heard are motivated to > comment. > > > Anyway, that said, I would like to see SendTargets stay > in the draft, mainly for the same reasons that several > others already stated: > > SendTargets shares the same authentication as iSCSI. > > SendTargets provides a simple, low-risk path to building > interoperable, minimal-configuration iSCSI implementations. > > SendTargets builds on the existing iSCSI login and text > commands, and will be the smallest-footprint and -effort > way to implement this basic functionality. > > The first reason given above is the most important. > > I believe that we should limit extensions to it as much as > possible, for instance, we should not attempt to return > certificates and other information. Implementations that > wish to do fancier things like these would implement one > of the other discovery mechanisms. We could go as far > as atrophying SendTargets later, but I think that John is > right, that it would be a decision to be made later (iSCSIv2). > > That said, I do agree that Julian is correct from a philosophical > point of view; discovery really belongs outside the protocol. > This is a direction we need to pursue. I absolutely agree with > Julian that we have to be careful not to let something like > SendTargets turn into a management protocol. It would be "easy > to do" :-). > > I see a mild consensus toward SLP as a good direction for > moving forward with discovery beyond simple target reporting. > The SLP folks themselves intended for hosts to be able to > behave in the Unicast manner we are trying, and are interested > in updating the SLP API to handle this. However, I think that > it would be best to use SendTargets for now, while we both > make sure that the right SLP API is developed, and that we > can solve the problem of authentication schemes. > > > On ReportPortalGroups > > I did not hear anyone say we didn't need this functionality; most > seemed to say the we either "at least" need ReportPortalGroups > if we don't have SendTargets, or that SendTargets was assumed, > and ReportPortalGroups is a subset. > > I agree that this is necessary functionality, but that if we > can assume that we still have SendTargets, ReportPortalGroups > is really a subset. Paul mentioned just using: > > SendTargets > > would be the same as ReportPortalGroups. This might help > avoid the feature creep that some of the responders feared. > > Anyway, either way of doing ReportPortalGroups (making it its > own command or making it part of SendTargets) is fine with me. > I think that the consensus was that as long as we have SendTargets, > we should use it for the ReportPortalGroups functionality. > > > On the Growth of SendTargets > > A few people mentioned concern about TargetAlias and digital > certificates. TargetAlias is returned by the target upon login > anyway, so I could live with removing it from SendTargets, and > letting the higher-level discovery/management mechanisms deal > with it. I think that the same goes for certificates. As we > figure out how our customers really want to do security for iSCSI, > we may have other mechanisms in place for handling these. > > This should help keep SendTargets from growing. Stating that > it is limited to name, address, and aggregation information (just > what is required to connect) should keep it right where it is, > and the future discovery mechanisms can take over from there. > > So here's what I think we have: > > Now - Keep SendTargets, document it in the iSCSI spec, and > declare its limitation to just what is needed to > connect to a target (name, address, aggregation). > > Define ReportPortalGroups functionality as a subset > of SendTargets. > > Future - Pursue SLP as the "standard discovery", allowing for > other solutions such as iSNS as appropriate. > > Do we have rough consensus on either of the above, at least > on the "Now" part? > > Once we have consensus on that, we can continue the threads > on aggregation tags, which targets should provide SendTargets, > and whether or not we need iterators. > > Anyway, I have to apologize in advance; I will be out of > the office until the 18th, so I am sort of throwing this out > on the list and running away. > > > Regards, > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Sun Jun 10 02:15:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06465 for ; Sun, 10 Jun 2001 02:15:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5A3x4H16867 for ips-outgoing; Sat, 9 Jun 2001 23:59:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5A3x3g16863 for ; Sat, 9 Jun 2001 23:59:03 -0400 (EDT) Received: from cs.uchicago.edu (h005018031eeb.ne.mediaone.net [24.91.84.19]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f5A3x1x29676 for ; Sat, 9 Jun 2001 23:59:01 -0400 (EDT) Message-Id: <200106100359.f5A3x1x29676@chmls05.mediaone.net> To: ips@ece.cmu.edu Subject: Re: Unsolicited Data. In-Reply-To: Message from "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" of "Thu, 07 Jun 2001 08:39:59 BST." <0B9A57FF1D57D411B47500D0B73E5CC101E7A73E@dickens.bri.hp.com> References: <0B9A57FF1D57D411B47500D0B73E5CC101E7A73E@dickens.bri.hp.com> Date: Sat, 09 Jun 2001 23:56:44 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk Matthew, > However, for large writes the unsolicited portion of the data need > not be all the data in the transfer but enough to overcome the > initial latency. I was probably unclear (well, OK, completely incoherent) in my previous message. Lemmie try it again. My point about large writes is that there are usually many of them outstanding concurrently. That's what file systems live for. The initial latency of the next write is covered by the terminal data transfer of the current write. As long as there's bandwidth * delay worth of total outstanding writes, you don't need unsolicited data. If you have an obscene bandwidth * delay, you might realistically expect that current file systems WON'T give you that much outstanding demand, so saving the startup latency with unsolicited data will improve performance somewhat. But not much. I'm claiming that's not a case worth optimizing. Steph From owner-ips@ece.cmu.edu Sun Jun 10 12:56:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11941 for ; Sun, 10 Jun 2001 12:56:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5AF2o202108 for ips-outgoing; Sun, 10 Jun 2001 11:02:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5ABUCg21021 for ; Sun, 10 Jun 2001 07:30:12 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA313656 for ; Sun, 10 Jun 2001 13:30:06 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5ABSnv98840 for ; Sun, 10 Jun 2001 13:28:49 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A67.003F1169 ; Sun, 10 Jun 2001 13:28:52 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sun, 10 Jun 2001 14:31:49 +0300 Subject: RE: Unsolicited Data. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk I've published the new text to this list a while ago. Please look-up the archives. Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" on 06-06-2001 17:35:38 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" cc: Subject: RE: Unsolicited Data. The current spec states that the F bit is "set to 1 when the immediate data that accompany the command are all the data associated with this command. It is an error if the Length and Expected Length do not match and this bit is set to 1". I interpret this as there is no more data to follow and not that the initiator has opted not to use the unsolicited data feature. Therefore the spec needs to be modified to indicate that if unsolicited data has been negotiated (i.e. InitialR2T=no), then the initiator MUST send unsolicited data of length = min( FirstBurstSize, ExpectedTransferLength ) minus any immediate data sent). Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Ayman Ghanem [mailto:aghanem@cisco.com] Sent: Tuesday, June 05, 2001 6:31 PM To: ips@ece.cmu.edu Subject: RE: Unsolicited Data. If the initiator decides not to send immediate or unsolicited data when it has negotiated to do so, then the initiator must set the F-bit in the command PDU. This prompts the target to send R2T. I still agree that the spec should indicate that the initiator MUST use the resources it has negotiated. If it has negotiated the option to send immediate data or unsolicited data then it should do that to the limits allowed. If it has negotiated a PDU length, it must not send data PDUs less than the negotiated limit except for last one. While most implementation may do that for performance reasons, I would prefer defining this in the spec. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > Sent: Tuesday, June 05, 2001 11:58 AM > To: 'ips@ece.cmu.edu' > Subject: Unsolicited Data. > > > I'm not sure if this has been discussed before but it is causing some > confusion. The statement below implies that if immediate data has been > negotiated then the initiator MAY use it. > > "If ImmediateData is set to no and InitialR2T is set to no then the > initiator MUST NOT send unsolicited immediate data but MAY send one > unsolicited burst of Data-OUT PDUs." > > Therefore the target must wait for the initial burst of unsolicited data > before issuing the first R2T (if there is subsequent data). If the > initiator decides not to send it then the target must timeout and > issue the > R2T for the initial data. Can the spec be changed to state that if > unsolicited data has been negotiated, then the initiator MUST use it. > > Thanks > > Matthew Burbridge > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > From owner-ips@ece.cmu.edu Sun Jun 10 12:58:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11952 for ; Sun, 10 Jun 2001 12:58:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5AF2Ux02095 for ips-outgoing; Sun, 10 Jun 2001 11:02:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5A5O7g21320 for ; Sun, 10 Jun 2001 01:24:07 -0400 (EDT) Received: from phys-ha3mpka.Eng.Sun.COM ([129.146.43.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA25939 for ; Sat, 9 Jun 2001 22:24:05 -0700 (PDT) Received: from sonu (sonu [129.146.48.127]) by phys-ha3mpka.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id WAA04228 for ; Sat, 9 Jun 2001 22:24:05 -0700 (PDT) Message-Id: <200106100524.WAA04228@phys-ha3mpka.Eng.Sun.COM> Date: Sat, 9 Jun 2001 22:25:35 -0700 (PDT) From: "Tanjore K. Suresh" Reply-To: "Tanjore K. Suresh" Subject: iSCSI version 0.6 - Query? To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4leF2BoYktjHsCZoLyzk6g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, Page 12, Last paragraph. Regarding the command sequence number. " The target MUST silently *ignore* any command outside this range or duplicates with in the range that have not been flagged with the retry bit (the X bit in the opcode)" Why ignore commands which are not in the expected range or duplicates with in the range? This type of ignoring could cause initator to cause some unnecessary recovery activity which could/may end up to be not good for the target which is hale and healthy. Such a command could have been errorneously numbered or errorneously checked for this condition or errnoneously delivered with sequence number change because of problems transporting it over the internet fabric. Hence, my opinion is appropriate error need to be returned for such command instead of ignoring. Comments? Thanks sureshtk I From owner-ips@ece.cmu.edu Sun Jun 10 13:00:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11994 for ; Sun, 10 Jun 2001 13:00:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5AF2MR02064 for ips-outgoing; Sun, 10 Jun 2001 11:02:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5A4iFg19224 for ; Sun, 10 Jun 2001 00:44:15 -0400 (EDT) Received: from phys-ha3mpka.Eng.Sun.COM ([129.146.19.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23549 for ; Sat, 9 Jun 2001 22:44:13 -0600 (MDT) Received: from sonu (sonu [129.146.48.127]) by phys-ha3mpka.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id VAA27308 for ; Sat, 9 Jun 2001 21:44:13 -0700 (PDT) Message-Id: <200106100444.VAA27308@phys-ha3mpka.Eng.Sun.COM> Date: Sat, 9 Jun 2001 21:45:44 -0700 (PDT) From: "Tanjore K. Suresh" Reply-To: "Tanjore K. Suresh" Subject: iSCSI 0.6 version, Question... To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jrsgTYUP/cddjZ2qmDiYHg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, Section 3 SCSI mode parameters for iSCSI I am wondering setting and querying the mode parameters what does it buy us when we have the text mode negotiations possible for the same parameters, except for CRN field via iSCSI control mode page. Can we completely eliminate this mode page reporting and only report it using text commands key=value pair method. Is there any advantage in having two mechanisms of reporting, which may be i am missing. One small change in the text at the beginning of the section 3. second paragraph "The mode parameters can be set and retrieved by scsi mode-set and ^^ mode select mode sense commands....." The "mode-set" should have been "mode select". I am sure somebody would have pointed this. Thanks sureshtk From owner-ips@ece.cmu.edu Mon Jun 11 10:34:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11739 for ; Mon, 11 Jun 2001 10:33:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BCP0P23088 for ips-outgoing; Mon, 11 Jun 2001 08:25:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BCOwg23084 for ; Mon, 11 Jun 2001 08:24:58 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA29552 for ; Mon, 11 Jun 2001 08:18:05 -0500 Received: from d04nms27.raleigh.ibm.com (d04nms27.raleigh.ibm.com [9.67.228.30]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5BCOoO33228 for ; Mon, 11 Jun 2001 08:24:51 -0400 Importance: Normal Subject: iSCSI: Send Targets and Report Portal Groups To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Joe Czap" Date: Mon, 11 Jun 2001 08:25:08 -0400 X-MIMETrack: Serialize by Router on D04NMS27/04/M/IBM(Release 5.0.6 |December 14, 2000) at 06/11/2001 08:24:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk SendTargets assumes that most initiators will need to discover and login to multiple targets. Given this assumption, the argument for including SendTargets seems pretty strong. It's simplicity allows any implementation to offer a discovery mechanism that would ease the burden of configuring target connectivity information on initiators. Initiators that only need to discover a single target name/address are not helped much by SendTargets. Although these initiators are not broken by SendTargets either. I also agree that leaving it in increases the likelihood that other features will creep in, but I think that the value gained by having SendTargets is worth the risk. Joe Czap IBM Storage Networking zapper@us.ibm.com From owner-ips@ece.cmu.edu Mon Jun 11 12:11:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13751 for ; Mon, 11 Jun 2001 12:11:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BEND701410 for ips-outgoing; Mon, 11 Jun 2001 10:23:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BENBg01406 for ; Mon, 11 Jun 2001 10:23:11 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA16862; Mon, 11 Jun 2001 10:15:21 -0400 Received: from d03nmx42.almaden.ibm.com (d03nmx42.almaden.ibm.com [9.1.24.146]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5BEN5B234258; Mon, 11 Jun 2001 08:23:05 -0600 Importance: Normal Subject: RE: iSCSI: Wrapping up SendTargets To: Joshua Tseng Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 11 Jun 2001 07:23:02 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NMX42/03/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 06/11/2001 07:23:05 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Josh, There is a fundamental difference of purpose behind SLPs and iSNS's. The things you list below as missing from SLP are *not* discovery functions but go well beyond that into more complex management. The purpose of the Naming and Discovery Team's effort is to define discovery: in short how does an initiator "walk the bus". We are not charged with full complex management issues. When scoped in this way, SLP seems perfectly suitable for discovery. I have more specific comments on your points below, tagged with .... As for the general question of SendTargets, here's my opinion: 1) I see no problem with SendTargets in the near term, it can be made obsolete in rev2 if that's the concensus at that time. 2) We should move toward putting that function within SLP in the mid-term. 3) There are open questions about how to deal with potentially long responses from SendTargets. This needs careful thought; all current proposals have problems or have been incompletely specified. 4) The ReportPortalGroups function is critical and needs to stay (for clarity, ReportPortalGroups is the Text command that requests, in the context of an established login to a full functioning iSCSI Target w/SCSI target, the list of ipaddress/tcpports+tags that express the sessioning coordination functions of the target). Whether the syntax of this is "SendTargets " or just "ReportPortalGroups" is immaterial (unless the expectation is that SendTargets goes obsolete in which case, the syntax should be stable, so perhaps a specific key for it would be best). Jim Hafner Joshua Tseng @ece.cmu.edu on 06/08/2001 06:26:01 PM Sent by: owner-ips@ece.cmu.edu To: "'Mark Bakke'" , IPS cc: Subject: RE: iSCSI: Wrapping up SendTargets Mark, > For adding discovery functionality beyond basic reporting > of available targets and addresses, I have seen 5 > (again, including myself) in favor of using SLP for > future discovery, one in favor of using iSNS for future > discovery, two in favor of either SLP or iSNS, and > three with no comment. > > I realize that this doesn't constitute calling consensus, > and I'm not the person to do it, but I wanted to point out > where most people who have responded seem to be headed, > so that others who wish to be heard are motivated to > comment. Am I missing something here? I had thought the previous discussions on this thread were regarding use of Sendtargets, not a referendum on SLP or iSNS. I am still waiting for a technical response to my previous messages over the last two months regarding iSNS and SLP. SLP lacks essential capabilities that iSNS provides, and no one has been able to explain how they will provide them with SLP or any other protocol. How can you possibly say we are headed in the direction of SLP when its technical issues as far as addressing storage discovery issues have not been resolved? > I see a mild consensus toward SLP as a good direction for > moving forward with discovery beyond simple target reporting. > The SLP folks themselves intended for hosts to be able to > behave in the Unicast manner we are trying, and are interested > in updating the SLP API to handle this. However, I think that > it would be best to use SendTargets for now, while we both > make sure that the right SLP API is developed, and that we > can solve the problem of authentication schemes. > Before you or anyone calls consensus, I would like to see how SLP can solve the following issues: 1) Management of Discovery Domains. You don't want incompatible file systems discovering each other, or very bad things will happen. Say 'goodbye' to the Unix file system who's host is discovered by SLP.... Discovery does not constitute a major exposure; discovery only lets an initiator know that something exists. The full security context of login is still there as the major barrior to authentication and authorization. So the integrity problem you speak of isn't there (in iSCSI, though it is there in FCP). 2) Transfer of X.509 digital certificates. SLP cannot easily transfer binary entities. This affects the iSCSI target device's ability to enforce its access control list. How so? Again, the SLP is only used to find the existence of the device. The iSCSI login does the hard part of enforcement and that happens on a completely different connection with a completely different protocol from SLP discovery. SLP isn't going to be used for the target to get its access control list (as you want iSNS to do). Configuration of those lists is NOT a discovery function and can be handled by direct management functions on the target. This may not be the cleanest way, but it is functional (it's what people are doing today in more contexts that just iSCSI). 3) Monitoring of available devices. SLP relies upon service agents re-registering periodically, in order to keep the freshness of its database entries. But this leads to a dilemma: if SA's re-register too often, the DA will be overwhelmed. And if they register not often enough, then you will have stale device entries. The fact is, SLP was not designed to be a real-time discovery protocol. But in storage networks, real-time information is crucial, as even slightly out-of-date information can lead to unnecessary logins and other events that will seriously degrade the performance of the storage network. I don't see this as a major problem either. Discovery and login should happen relatively infrequently in a storage network (e.g., at boot time or "rescan" time). Slightly stale information is probably not a major problem and will almost certainly only affect a limited number of systems. 4) State Change Notifications. This is important to support failover and redundancy capabilities, and to ensure that initiators can persistently maintain their sessions with targets in the event of network topology changes. > > Now - Keep SendTargets, document it in the iSCSI spec, and > declare its limitation to just what is needed to > connect to a target (name, address, aggregation). > > Define ReportPortalGroups functionality as a subset > of SendTargets. I understand you'll be out of contact for the next 1.5 weeks, and so you must be in a rush, but I must ask that you give us a at least a few days or so to digest the 10+ messages on this subject. I personally have been in-and-out of the office for the past couple days and haven't been able to respond till now. Once again, I support John's proposal to move Sendtargets to the annex. I don't think Sendtargets should be in the main document. Furthermore, it would be helpful if you clarify whether your statements are representing the iSCSI NDT or only of your personal views. I do not believe your statements regarding the SLP approach for iSCSI are consistent with what was agreed to in the NDT. I believe the consensus was that both iSNS and SLP are to be considered for discovery. > Future - Pursue SLP as the "standard discovery", allowing for > other solutions such as iSNS as appropriate. As an NDT member, I cannot support a decision on making any protocol the "standard" without fully addressing the above technical issues. The devil is in the details, and only after exploring such issues will we be able to avoid future pitfalls that may threaten the timely adoption of iSCSI. Josh > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Friday, June 08, 2001 1:31 PM > To: IPS > Subject: iSCSI: Wrapping up SendTargets > > > > Dear Discovery Enthusiasts- > > The SendTargets threads are winding down, so I would like > to see if we have a rough consensus on a few things. > > > I've read through all of the threads on whether to > keep SendTargets in iSCSI, and I believe there is > a rough concensus that we should keep it in, carefully > limit its growth, and recommend that functionality > beyond the basic reporting of the targets and addresses > available be implemented using standard discovery > protocols instead. On looking through responses from > Josh, Steph, Larry, Paul, Julian, Mallikarjun, John, > Kaladhar, Jim, and Marjorie, I have seen 7 (I include > myself in this count) in favor of keeping SendTargets > but limiting its growth, one in favor of dropping > SendTargets, and three with no comment on SendTargets. > > For adding discovery functionality beyond basic reporting > of available targets and addresses, I have seen 5 > (again, including myself) in favor of using SLP for > future discovery, one in favor of using iSNS for future > discovery, two in favor of either SLP or iSNS, and > three with no comment. > > I realize that this doesn't constitute calling consensus, > and I'm not the person to do it, but I wanted to point out > where most people who have responded seem to be headed, > so that others who wish to be heard are motivated to > comment. > > > Anyway, that said, I would like to see SendTargets stay > in the draft, mainly for the same reasons that several > others already stated: > > SendTargets shares the same authentication as iSCSI. > > SendTargets provides a simple, low-risk path to building > interoperable, minimal-configuration iSCSI implementations. > > SendTargets builds on the existing iSCSI login and text > commands, and will be the smallest-footprint and -effort > way to implement this basic functionality. > > The first reason given above is the most important. > > I believe that we should limit extensions to it as much as > possible, for instance, we should not attempt to return > certificates and other information. Implementations that > wish to do fancier things like these would implement one > of the other discovery mechanisms. We could go as far > as atrophying SendTargets later, but I think that John is > right, that it would be a decision to be made later (iSCSIv2). > > That said, I do agree that Julian is correct from a philosophical > point of view; discovery really belongs outside the protocol. > This is a direction we need to pursue. I absolutely agree with > Julian that we have to be careful not to let something like > SendTargets turn into a management protocol. It would be "easy > to do" :-). > > I see a mild consensus toward SLP as a good direction for > moving forward with discovery beyond simple target reporting. > The SLP folks themselves intended for hosts to be able to > behave in the Unicast manner we are trying, and are interested > in updating the SLP API to handle this. However, I think that > it would be best to use SendTargets for now, while we both > make sure that the right SLP API is developed, and that we > can solve the problem of authentication schemes. > > > On ReportPortalGroups > > I did not hear anyone say we didn't need this functionality; most > seemed to say the we either "at least" need ReportPortalGroups > if we don't have SendTargets, or that SendTargets was assumed, > and ReportPortalGroups is a subset. > > I agree that this is necessary functionality, but that if we > can assume that we still have SendTargets, ReportPortalGroups > is really a subset. Paul mentioned just using: > > SendTargets > > would be the same as ReportPortalGroups. This might help > avoid the feature creep that some of the responders feared. > > Anyway, either way of doing ReportPortalGroups (making it its > own command or making it part of SendTargets) is fine with me. > I think that the consensus was that as long as we have SendTargets, > we should use it for the ReportPortalGroups functionality. > > > On the Growth of SendTargets > > A few people mentioned concern about TargetAlias and digital > certificates. TargetAlias is returned by the target upon login > anyway, so I could live with removing it from SendTargets, and > letting the higher-level discovery/management mechanisms deal > with it. I think that the same goes for certificates. As we > figure out how our customers really want to do security for iSCSI, > we may have other mechanisms in place for handling these. > > This should help keep SendTargets from growing. Stating that > it is limited to name, address, and aggregation information (just > what is required to connect) should keep it right where it is, > and the future discovery mechanisms can take over from there. > > So here's what I think we have: > > Now - Keep SendTargets, document it in the iSCSI spec, and > declare its limitation to just what is needed to > connect to a target (name, address, aggregation). > > Define ReportPortalGroups functionality as a subset > of SendTargets. > > Future - Pursue SLP as the "standard discovery", allowing for > other solutions such as iSNS as appropriate. > > Do we have rough consensus on either of the above, at least > on the "Now" part? > > Once we have consensus on that, we can continue the threads > on aggregation tags, which targets should provide SendTargets, > and whether or not we need iterators. > > Anyway, I have to apologize in advance; I will be out of > the office until the 18th, so I am sort of throwing this out > on the list and running away. > > > Regards, > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Mon Jun 11 12:15:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13818 for ; Mon, 11 Jun 2001 12:15:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BEnXN03415 for ips-outgoing; Mon, 11 Jun 2001 10:49:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BEnWg03411 for ; Mon, 11 Jun 2001 10:49:32 -0400 (EDT) Received: from cs.uchicago.edu (h005018031eeb.ne.mediaone.net [24.91.84.19]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f5BEnTx02921; Mon, 11 Jun 2001 10:49:29 -0400 (EDT) Message-Id: <200106111449.f5BEnTx02921@chmls05.mediaone.net> To: ips@ece.cmu.edu cc: +iscsi@chmls05.mediaone.net Subject: Re: iSCSI: Send Targets and Report Portal Groups In-Reply-To: Message from "Joe Czap" of "Mon, 11 Jun 2001 08:25:08 EDT." References: Date: Mon, 11 Jun 2001 10:47:10 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk Joe, > Initiators that only need to discover a single target name/address are not > helped much by SendTargets. They are if they don't already know the target's name, and there is not a default operational target. I do think that single target end points are going to be a common case. The question is whether you require the initiator to know the network address (probably just IP address or name) AND the target name, or just the network address. If you have a default operational target, OR if you provide SendTargets, you only need to know the network address. Otherwise, you need to know the target name too. Personally, I think that requiring that an initiator know both the address and the target name (OR requiring an N/D service) is a mistake. It means an administrator must be able to find each target's address through a side channel. If the target is racked into a large system, you probably won't be able to read it off the box itself, and it may not have an appropriate console or other facility from which to interrogate the target. I'll renew my claim that to get started in iSCSI, it shouldn't be necessary to have additional `enterprise-class' resources (i.e. a complete N/D service). It should be easy to stage a SMALL configuration by just: 1) configuring the initiator to be a network citizen 2) configuring the target(s) to be a network citizen 3) pointing the initiator at the target This is analogous to what PL_DA offered for FC. Certainly, much of the sizzle of FC is in the larger network case, but first people put together PL_DA configurations (and products), before deciding it was time to try something bigger. In other words, we need either SendTargets OR a default operational target (and I say why not both?) to support this simple case. We shouldn't throw BOTH of these out. Steph From owner-ips@ece.cmu.edu Mon Jun 11 12:46:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14493 for ; Mon, 11 Jun 2001 12:46:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BEJK601086 for ips-outgoing; Mon, 11 Jun 2001 10:19:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BEJIg01081 for ; Mon, 11 Jun 2001 10:19:18 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-139.cisco.com [161.44.68.139]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA27766 for ; Mon, 11 Jun 2001 10:19:12 -0400 (EDT) From: "Ayman Ghanem" To: Subject: iSCSI: MaxCmdSN Date: Mon, 11 Jun 2001 09:18:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In section 2.4.10, "if the PDU MaxCmdSN is less than the PDU ExpCmdSN ...., they are both ignored". Is this considered an invalid response from the target?. What happens when the target queuing capacity reaches 0. For example: target received and processed cmdsn N, but can not receive cmdsn N+1 yet. In the response for N, target puts N+1 for expectedCmdSN. How does it inform the initiator that its window is closed?. Setting MaxCmdSN to N will be ignored if I understand the above paragraph correctly. -Ayman From owner-ips@ece.cmu.edu Mon Jun 11 14:33:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16434 for ; Mon, 11 Jun 2001 14:33:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BGD7X10421 for ips-outgoing; Mon, 11 Jun 2001 12:13:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com ([217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BGD6g10417 for ; Mon, 11 Jun 2001 12:13:06 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 17:14:05 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B96A3@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Julian Satran'" , "'ISCSI'" Subject: iSCSI:- SCSI response Flags Date: Mon, 11 Jun 2001 17:14:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F289.2692A540" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F289.2692A540 Content-Type: text/plain; charset="iso-8859-1" there is some mistake in definition of flags byte in SCSI Response Current definition says b3 (u) same as b0 but for the read-part of a bi-directional operation b4 (o) same as b1 but for the read-part of a bi-directional operation it should be b3 (u) same as b1 but for the read-part of a bi-directional operation b4 (o) same as b2 but for the read-part of a bi-directional operation Also the line Bits O and U are mutually exclusive and so are bits o and u. For a response (S=0) b0-b3 MUST be 0. should change to Bits O and U are mutually exclusive and so are bits o and u. For a response (S=0) b1-b4 MUST be 0. or Bits O and U are mutually exclusive and so are bits o and u. For a response (S=0) b0-b4 MUST be 0. Regards, Sanjeev ------_=_NextPart_001_01C0F289.2692A540 Content-Type: text/html; charset="iso-8859-1"

 
there is some mistake in definition of flags byte in SCSI Response
 
Current definition says

b3 (u) same as b0 but for the read-part of a bi-directional  operation

b4 (o) same as b1 but for the read-part of a bi-directional operation

it should be

b3 (u) same as b1 but for the read-part of a bi-directional  operation

b4 (o) same as b2 but for the read-part of a bi-directional operation

Also the line

Bits O and U are mutually exclusive and so are bits o and u.  For a response (S=0) b0-b3 MUST be 0.

should change to

Bits O and U are mutually exclusive and so are bits o and u.  For a response (S=0) b1-b4 MUST be 0.

or

Bits O and U are mutually exclusive and so are bits o and u.  For a response (S=0) b0-b4 MUST be 0.

 

Regards,

Sanjeev

 

------_=_NextPart_001_01C0F289.2692A540-- From owner-ips@ece.cmu.edu Mon Jun 11 14:37:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16515 for ; Mon, 11 Jun 2001 14:37:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BGD1O10413 for ips-outgoing; Mon, 11 Jun 2001 12:13:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com ([217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BGCxg10404 for ; Mon, 11 Jun 2001 12:12:59 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 18:10:27 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B96A6@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Julian Satran'" , "'ISCSI'" , "'Mark Bakke'" , "'Ralph Weber'" Subject: iSCSI: Response codes in SCSI Response Command Date: Mon, 11 Jun 2001 18:10:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F291.0691EBE0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F291.0691EBE0 Content-Type: text/plain; charset="iso-8859-1" Current definition states 2.4.2 Status/Response The Status field is used to report the SCSI status of the command (as specified in [SAM2]). The Response is used to report a Service Response. The exact mapping of the iSCSI response codes to SAM service response symbols is outside the scope of this document. If a SCSI device error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set) the target MUST wait until it receives the a data PDU with the F bit set before sending the Response PDU. Valid iSCSI Response codes are: 0x01 - Target Failure 0x02 - Delivery Subsystem Failure 0x03 - Unsolicited data rejected 0x04 - SNACK rejected 0x80-0xff - Reserved for Vendor-Unique Responses DONT YOU THINK that these response codes be actually mapped in SAM document and be made as standard to be followed by any protocol. So iSCSI should also report the same responses as defined in SAM document. Regards, Sanjeev ------_=_NextPart_001_01C0F291.0691EBE0 Content-Type: text/html; charset="iso-8859-1"
Current definition states
 

2.4.2 Status/Response

The Status field is used to report the SCSI status of the command (as specified in [SAM2]). The Response is used to report a Service Response. The exact mapping of the iSCSI response codes to SAM service response symbols is outside the scope of this document. If a SCSI device error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set) the target MUST wait until it receives the a data PDU with the F bit set before sending the Response PDU.

Valid iSCSI Response codes are:

0x01 - Target Failure

0x02 - Delivery Subsystem Failure

0x03 - Unsolicited data rejected

0x04 - SNACK rejected

0x80-0xff - Reserved for Vendor-Unique Responses

 

DONT YOU THINK that these response codes be actually mapped in SAM document and be made as standard to be followed by any protocol. So iSCSI should also report the same responses as defined in SAM document.

Regards,

Sanjeev

 

------_=_NextPart_001_01C0F291.0691EBE0-- From owner-ips@ece.cmu.edu Mon Jun 11 14:49:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16685 for ; Mon, 11 Jun 2001 14:49:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BH0YA14131 for ips-outgoing; Mon, 11 Jun 2001 13:00:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BH0Ug14122 for ; Mon, 11 Jun 2001 13:00:30 -0400 (EDT) Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345) id C1B18592; Mon, 11 Jun 2001 10:02:18 -0700 (PDT) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 837756DE; Mon, 11 Jun 2001 10:02:13 -0700 (PDT) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 11 Jun 2001 12:00:17 -0500 Message-ID: <31891B757C09184BBFEC5275F85D5595104D73@cceexc18.americas.cpqcorp.net> From: "Martin, Nick" To: "'Ayman Ghanem'" , ips@ece.cmu.edu Subject: RE: iSCSI: MaxCmdSN Date: Mon, 11 Jun 2001 11:59:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ayman, I thought I understood this, and I had a great explanation supporting the draft (06), but I now realize I was "off by one". I believe you are correct that ExpCmdSN will be one greater than MaxCmdSN if-and-only-if an acknowledgement is to be sent while the window is closed. The purpose of ExpCmdSN and MaxCmdSN transmitted by the target, is to advance values with the same names maintained in the initiator. ExpCmdSN acknowledges receipt of all CmdSN values < ExpCmdSN. MaxCmdSN is the largest CmdSN the target promises to accept, and conversely the largest CmdSN the initiator is permitted to send. The target can not regress these numbers in the initiator. When the target transmits (and the initiator accepts) N as the MaxCmdSN, the initiator is allowed to transmit CmdSN values through N. Then it must stop. Any number of additional PDUs may carry the same MaxCmdSN value. None of these will cause the initiator's value to advance. A response carrying a MaxCmdSN less than the initiator's current MaxCmdSN value is presumed to have arrived late. It does not advance nor regress the initiator's present value. After the initiator sends CmdSN of MaxCmdSN (still N), it can not send any more until MaxCmdSN advances. It should be permitted for the target to acknowledge the receipt of all commands received through this CmdSN which is N. In this case ExpCmdSN would be N + 1 and MaxCmdSN is still N. We know that no commands are in flight. When the target is able to accept another command, it must advance MaxCmdSN (value > N in serial arithmetic), and it will send the new value to the initiator in the next inbound PDU (i.e. data-in, SCSI response, or nop-in). Yes, I believe it would be a protocol error for MaxCmdSN to have a value less than ExpCmdSN - 1. This would be an acknowledgement for a CmdSN which the initiator was not yet permitted to send. I think MaxCmdSN equal to ExpCmdSN - 1 should be permitted. Note however that nothing will break if this acknowledgement is not immediately sent or, having been sent, does not advance the initiator's values. The window is already closed and remains so. While the window is closed, the initiator will be holding the last PDU sent as unacknowledged, when the target has in fact received it. The PDU will be successfully acknowledged when MaxCmdSN advances, because ExpCmdSN in the target will not advance simultaneously while the window is closed. Was this done intentionally to delay the last acknowledgement when the window is closed, or is it an "off by one" issue in draft 06? This made me think about a related issue: It think it would be permitted for the target to reject or drop a PDU with CmdSN greater than MaxCmdSN, but I am not sure if it is required to do so. I do not see a response code the target could send that would tell the initiator what it did wrong. Thanks, Nick -----Original Message----- From: Ayman Ghanem [mailto:aghanem@cisco.com] Sent: Monday, June 11, 2001 9:18 AM To: ips@ece.cmu.edu Subject: iSCSI: MaxCmdSN In section 2.4.10, "if the PDU MaxCmdSN is less than the PDU ExpCmdSN ...., they are both ignored". Is this considered an invalid response from the target?. What happens when the target queuing capacity reaches 0. For example: target received and processed cmdsn N, but can not receive cmdsn N+1 yet. In the response for N, target puts N+1 for expectedCmdSN. How does it inform the initiator that its window is closed?. Setting MaxCmdSN to N will be ignored if I understand the above paragraph correctly. -Ayman From owner-ips@ece.cmu.edu Mon Jun 11 14:50:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16714 for ; Mon, 11 Jun 2001 14:50:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BGusX13821 for ips-outgoing; Mon, 11 Jun 2001 12:56:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BGupg13810 for ; Mon, 11 Jun 2001 12:56:51 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id E471D155 for ; Mon, 11 Jun 2001 18:56:45 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id RAA23170 for ; Mon, 11 Jun 2001 17:56:45 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Mon, 11 Jun 2001 17:56:45 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 17:56:45 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A747@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu Subject: RE: Unsolicited Data. Date: Mon, 11 Jun 2001 17:56:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Julian Sorry about harking on with this one but I still don't feel that it has been resolved. By the new text are you referring to http://ips.pdl.cs.cmu.edu/mail/msg04647.html? If so it does not take into account the issue that I am trying to resolve: If an initiator and target have negotiated to use unsolicited data PDUs(InitialR2t=no), how does an target know that an initiator is going to sent unsolicited SCSI Data PDUs when it is optional to send unsolicited data PDUs? Mallikarjun has suggested a solution which will work providing that immediate data and unsolicited Data PDUs can not be used together (which is what Rev 06 states). Am I correct it believe this is still the case - I seem to remember a thread suggesting otherwise. The other option, which is less flexible is that if both sides have negotiated to use unsolicited Data PDUs (InitialR2t=no), then it MUST always send unsolicited data which needs to be reflected in the specification. Cheers Matthew -----Original Message----- From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] Sent: Sunday, June 10, 2001 12:32 PM To: ips@ece.cmu.edu Subject: RE: Unsolicited Data. I've published the new text to this list a while ago. Please look-up the archives. Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" on 06-06-2001 17:35:38 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" cc: Subject: RE: Unsolicited Data. The current spec states that the F bit is "set to 1 when the immediate data that accompany the command are all the data associated with this command. It is an error if the Length and Expected Length do not match and this bit is set to 1". I interpret this as there is no more data to follow and not that the initiator has opted not to use the unsolicited data feature. Therefore the spec needs to be modified to indicate that if unsolicited data has been negotiated (i.e. InitialR2T=no), then the initiator MUST send unsolicited data of length = min( FirstBurstSize, ExpectedTransferLength ) minus any immediate data sent). Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Ayman Ghanem [mailto:aghanem@cisco.com] Sent: Tuesday, June 05, 2001 6:31 PM To: ips@ece.cmu.edu Subject: RE: Unsolicited Data. If the initiator decides not to send immediate or unsolicited data when it has negotiated to do so, then the initiator must set the F-bit in the command PDU. This prompts the target to send R2T. I still agree that the spec should indicate that the initiator MUST use the resources it has negotiated. If it has negotiated the option to send immediate data or unsolicited data then it should do that to the limits allowed. If it has negotiated a PDU length, it must not send data PDUs less than the negotiated limit except for last one. While most implementation may do that for performance reasons, I would prefer defining this in the spec. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > Sent: Tuesday, June 05, 2001 11:58 AM > To: 'ips@ece.cmu.edu' > Subject: Unsolicited Data. > > > I'm not sure if this has been discussed before but it is causing some > confusion. The statement below implies that if immediate data has been > negotiated then the initiator MAY use it. > > "If ImmediateData is set to no and InitialR2T is set to no then the > initiator MUST NOT send unsolicited immediate data but MAY send one > unsolicited burst of Data-OUT PDUs." > > Therefore the target must wait for the initial burst of unsolicited data > before issuing the first R2T (if there is subsequent data). If the > initiator decides not to send it then the target must timeout and > issue the > R2T for the initial data. Can the spec be changed to state that if > unsolicited data has been negotiated, then the initiator MUST use it. > > Thanks > > Matthew Burbridge > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > From owner-ips@ece.cmu.edu Mon Jun 11 15:05:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17000 for ; Mon, 11 Jun 2001 15:05:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BH8Gm14709 for ips-outgoing; Mon, 11 Jun 2001 13:08:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BH8Dg14702 for ; Mon, 11 Jun 2001 13:08:13 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id B3E8D4E for ; Mon, 11 Jun 2001 19:08:07 +0200 (METDST) Received: from loddon.br.itc.hp.com (loddon.br.itc.hp.com [15.145.8.166]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id SAA25934 for ; Mon, 11 Jun 2001 18:08:07 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Mon, 11 Jun 2001 18:08:07 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 18:08:07 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A748@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: Task Management Commands and Immediate Delivery. Date: Mon, 11 Jun 2001 18:08:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0F299.13FA4220" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0F299.13FA4220 Content-Type: text/plain; charset="ISO-8859-1" We have been working through section 7.3 and were unclear on a few areas. Essentially, the algorithm is fine but we felt that there were are number of areas that either need clarifying or expanding. Attached is an 'updated' version of the section that addresses the issues. The algorithm relies on both the initiator and target performing the exact same action to remove items off of the command queues otherwise there could be either a discrepancy between the two sides. Another alternative is for the target to inform the initiator of those commands that have been aborted in the iSCSI layer (but not the SCSI layer). In which case there is no need to implement the algorithm in the initiator. Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com ------_=_NextPart_000_01C0F299.13FA4220 Content-Type: text/plain; name="Section 7.3.txt" Content-Disposition: attachment; filename="Section 7.3.txt" Content-Transfer-Encoding: quoted-printable 7.3 Task Management Commands and Immediate Delivery=20 =20 A task management command may reach the target and, in the case that immediate delivery was requested, be executed before all of the = tasks=20 it was meant to act upon have been delivered or even reached the=20 target.=20 =20 It is assumed that, while pending delivery from iSCSI to SCSI at the = target, commands are kept in an iSCSI queue at both the initiator = and=20 the target and that the target queue contains both commands and=20 "holes" (placeholders for commands not received yet).=20 =20 The following general mechanism can be used to achieve the effect of = ordered delivery for task management commands while enabling the =20 "urgent" delivery that some of them imply and immediate execution of = the task management commands. The mechanism manages discarding commands while they are in the iSCSI layer at the target and prevents these discarded commands from being delivered to the target's SCSI layer. The initiator must keep a record of these commands to determine which will not receive a response. The target does not generate a response to a command that is aborted while in the iSCSI layer. The "barrier list" described in the following sections is a list containing information relating to all task management commands marked for immediate delivery. =20 At the initiator when a relevant task management marked for immediate delivery command is issued:=20 =20 a) if ExpCmdSN is equal to CmdSN then there are no commands in the queue so skip to step c. b) mark all pending commands with a CmdSN field between the current ExpCmdSN and the current CmdSN that are candidates for cleanup and retain the CmdSN of the task management command in a "barrier list"[ET1]. =20 c) send the task management command for immediate delivery. to the target. =20 Note: for clarity, the barrier list contains "items" and the command queue contains "entries". At the initiator when updating ExpCmdSN:=20 =20 a) if the "barrier list" is empty or ExpCmdSN is less than the CmdSN of the oldest item in the barrier list then skip to step d=20 b) remove the oldest barrier list item, and remove and = silently discard all entries marked for cleanup having a CmdSN field less than ExpCmdSN. These entries have been aborted by the target while they were in the target's iSCSI layer.=20 c) go to step a and repeat steps a and b on the next item in = the barrier list if it has not become empty d) release all queued entries between the old and new ExpCmdSN from the queue. Note: Any entries that had been marked as a candidate for cleanup have now been delivered by the target to its SCSI layer. The SCSI layer will have to determine = if they are to be aborted. At the target when receiving a relevant task management command = for=20 immediate delivery:=20 =20 a) if ExpCmdSN is equal to CmdSN then there are no commands in = the queue so skip to step c. b) mark all pending entries (commands received and = placeholders) with a CmdSN between ExpCmdSN and the current CmdSN as = candidates for cleanup and retain the CmdSN of this task management = command in a "barrier list" including criteria for candidacy.=09 c) send the task management command to SCSI for immediate = execution =20 At the target when updating ExpCmdSN (releasing ordered commands = to=20 SCSI):=20 =20 a) if the "barrier list" is empty or ExpCmdSN is less than the = oldest item in the barrier list then skip to step d b) remove the oldest barrier list item and evaluate all queued = entries that have a CmdSN field less than ExpCmdSN, removing and = silently discarding each queued command that meets the criteria for = cleanup candidacy (as specified by the task management function). c) go to step a and repeat steps a and b on the next item in = the barrier list if it has not become empty d) release all queued entries between the old and new ExpCmdSN = from the queue=20 =20 Note that this scheme will withstand connection recovery. =20 The selection of candidates is implementation dependant. A queue = entry can be validated for candidacy for example when the task = management command is received, or when the SCSI command in the queue entry = is delivered to the SCSI layer. =20 = +---+--------------------+-------------------------------------------+ |No | Function | Candidacy Selection = | = +---+--------------------+-------------------------------------------+ | 1 | Abort Task | All tasks that are identified by the = | | | | Referenced Task Tag Field. = | = +---+--------------------+-------------------------------------------+ | 2 | Abort Task Set | All tasks associated with the = specified | | | | LUN and initiator. = | = +---+--------------------+-------------------------------------------+ | 3 | Clear ACA | No entries are marked for candidacy. = | = +---+--------------------+-------------------------------------------+ | 4 | Clear Task Set | All tasks associated with the = specified | | | | LUN. = | = +---+--------------------+-------------------------------------------+ | 5 | Logical Unit Reset | No entries are marked for candidacy. = | = +---+--------------------+-------------------------------------------+ | 6 | Target Warm Reset | No entries are marked for candidacy. = | = +---+--------------------+-------------------------------------------+ | 7 | Target Cold Reset | No entries are marked for candidacy. = | = +---+--------------------+-------------------------------------------+ ------_=_NextPart_000_01C0F299.13FA4220-- From owner-ips@ece.cmu.edu Mon Jun 11 15:35:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17523 for ; Mon, 11 Jun 2001 15:35:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BHRwD16329 for ips-outgoing; Mon, 11 Jun 2001 13:27:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BHRvg16324 for ; Mon, 11 Jun 2001 13:27:57 -0400 (EDT) Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345) id DF04D42A; Mon, 11 Jun 2001 10:29:45 -0700 (PDT) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 267BA706; Mon, 11 Jun 2001 10:29:45 -0700 (PDT) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 11 Jun 2001 12:27:49 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C659C217@cceexc17.americas.cpqcorp.net> From: "Elliott, Robert" To: "'ISCSI'" , "'Sanjeev Bhagat (TRIPACE/Zoetermeer)'" Subject: RE: iSCSI: Response codes in SCSI Response Command Date: Mon, 11 Jun 2001 12:27:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk SPI-4, FCP-2, SRP, and SST do agree on these values: 0 - task management function complete 1 - FCP specific 2 - command IU/request fields invalid 3 - FCP specific 4 - task management function not supported 5 - task management function failed 6+ - protocol specific It's too late to try to force any more commonality, as those standards already exist. iSCSI has separate command response and task management response IUs (PDUs), making it a bit different from the other protocols. --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com -----Original Message----- From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] Sent: Monday, June 11, 2001 11:10 AM To: 'Julian Satran'; 'ISCSI'; 'Mark Bakke'; 'Ralph Weber' Subject: iSCSI: Response codes in SCSI Response Command Current definition states 2.4.2 Status/Response The Status field is used to report the SCSI status of the command (as specified in [SAM2]). The Response is used to report a Service Response. The exact mapping of the iSCSI response codes to SAM service response symbols is outside the scope of this document. If a SCSI device error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set) the target MUST wait until it receives the a data PDU with the F bit set before sending the Response PDU. Valid iSCSI Response codes are: 0x01 - Target Failure 0x02 - Delivery Subsystem Failure 0x03 - Unsolicited data rejected 0x04 - SNACK rejected 0x80-0xff - Reserved for Vendor-Unique Responses DONT YOU THINK that these response codes be actually mapped in SAM document and be made as standard to be followed by any protocol. So iSCSI should also report the same responses as defined in SAM document. Regards, Sanjeev From owner-ips@ece.cmu.edu Mon Jun 11 16:45:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18607 for ; Mon, 11 Jun 2001 16:45:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BIZN221586 for ips-outgoing; Mon, 11 Jun 2001 14:35:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BIZKg21581 for ; Mon, 11 Jun 2001 14:35:21 -0400 (EDT) Received: from hpcc01.corp.hp.com (hpcc01.corp.hp.com [15.0.120.1]) by palrel2.hp.com (Postfix) with ESMTP id ECAB65EE; Mon, 11 Jun 2001 11:35:19 -0700 (PDT) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by hpcc01.corp.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.3 SMKit7.0) id LAA09522; Mon, 11 Jun 2001 11:35:19 -0700 (PDT) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 11:35:17 -0700 Message-ID: <499DC368E25AD411B3F100902740AD6507778CD1@xrose03.rose.hp.com> From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Jim Hafner'" , Joshua Tseng Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Mon, 11 Jun 2001 11:35:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I support Mark's proposal and comments. I'd like to add something to Jim's. > > As for the general question of SendTargets, here's my opinion: > > 1) I see no problem with SendTargets in the near term, it can be made > obsolete in rev2 if that's the concensus at that time. It doesn't seem like a good idea to consider obsoleting something in the spec at this point. If SendTargets stays-in and it gets used (which I believe it will), it will need to continue to be supported - unless you don't expect rev2 iSCSI targets to talk with rev1 iSCSI initiators. So for rev2, rather than simply considering obsolescence at this point, we should consider adding additional functionality to SendTargets as well. Perhaps SLP is the right place for major new functionality, but we shouldn't rule out updates to SendTargets, especially if ReportPortalGroups must stay around. Paul +--------------------------+----------------------------+ + Paul Congdon + Email: paul_congdon@hp.com + + Hewlett Packard Company + Mail Stop: 5662 + + HP ProCurve Networking + Phone: (916) 785-5753 + + 8000 Foothills Blvd + Fax: (916) 785-5949 + + Roseville, CA 95747 + Mobile: (916) 765-4056 + +--------------------------+----------------------------+ From owner-ips@ece.cmu.edu Mon Jun 11 16:46:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18634 for ; Mon, 11 Jun 2001 16:46:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BJCFr24636 for ips-outgoing; Mon, 11 Jun 2001 15:12:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BJCDg24628 for ; Mon, 11 Jun 2001 15:12:13 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-139.cisco.com [161.44.68.139]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA17165 for ; Mon, 11 Jun 2001 15:12:07 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iSCSI: MaxCmdSN Date: Mon, 11 Jun 2001 14:11:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <31891B757C09184BBFEC5275F85D5595104D73@cceexc18.americas.cpqcorp.net> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nick, Yes, it will be an error for MaxCmdSN to have a value < (ExpCmdSN - 1), and I agree that MaxCmdSN = (ExpCmdSN - 1) should be permitted. As for the target receiving a PDU with CmdSN > MaxCmdSN, it is stated in draft-06 (near the end of 1.2.2.1) that the target MUST silently ignore such a command. No reject PDU needs to be sent. -Ayman > -----Original Message----- > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > Sent: Monday, June 11, 2001 12:00 PM > To: 'Ayman Ghanem'; ips@ece.cmu.edu > Subject: RE: iSCSI: MaxCmdSN > > > Ayman, > > I thought I understood this, and I had a great explanation supporting the > draft (06), but I now realize I was "off by one". I believe you > are correct > that ExpCmdSN will be one greater than MaxCmdSN if-and-only-if an > acknowledgement is to be sent while the window is closed. > > The purpose of ExpCmdSN and MaxCmdSN transmitted by the target, is to > advance values with the same names maintained in the initiator. ExpCmdSN > acknowledges receipt of all CmdSN values < ExpCmdSN. MaxCmdSN is the > largest CmdSN the target promises to accept, and conversely the largest > CmdSN the initiator is permitted to send. > > The target can not regress these numbers in the initiator. When > the target > transmits (and the initiator accepts) N as the MaxCmdSN, the initiator is > allowed to transmit CmdSN values through N. Then it must stop. > Any number > of additional PDUs may carry the same MaxCmdSN value. None of these will > cause the initiator's value to advance. A response carrying a > MaxCmdSN less > than the initiator's current MaxCmdSN value is presumed to have arrived > late. It does not advance nor regress the initiator's present value. > > After the initiator sends CmdSN of MaxCmdSN (still N), it can not send any > more until MaxCmdSN advances. It should be permitted for the target to > acknowledge the receipt of all commands received through this > CmdSN which is > N. In this case ExpCmdSN would be N + 1 and MaxCmdSN is still N. We know > that no commands are in flight. When the target is able to accept another > command, it must advance MaxCmdSN (value > N in serial arithmetic), and it > will send the new value to the initiator in the next inbound PDU (i.e. > data-in, SCSI response, or nop-in). > > Yes, I believe it would be a protocol error for MaxCmdSN to have a value > less than ExpCmdSN - 1. This would be an acknowledgement for a > CmdSN which > the initiator was not yet permitted to send. I think MaxCmdSN equal to > ExpCmdSN - 1 should be permitted. > > Note however that nothing will break if this acknowledgement is not > immediately sent or, having been sent, does not advance the initiator's > values. The window is already closed and remains so. While the window is > closed, the initiator will be holding the last PDU sent as unacknowledged, > when the target has in fact received it. The PDU will be successfully > acknowledged when MaxCmdSN advances, because ExpCmdSN in the > target will not > advance simultaneously while the window is closed. > > Was this done intentionally to delay the last acknowledgement when the > window is closed, or is it an "off by one" issue in draft 06? > > This made me think about a related issue: > It think it would be permitted for the target to reject or drop a PDU with > CmdSN greater than MaxCmdSN, but I am not sure if it is required to do so. > I do not see a response code the target could send that would tell the > initiator what it did wrong. > > Thanks, > Nick > > -----Original Message----- > From: Ayman Ghanem [mailto:aghanem@cisco.com] > Sent: Monday, June 11, 2001 9:18 AM > To: ips@ece.cmu.edu > Subject: iSCSI: MaxCmdSN > > > In section 2.4.10, "if the PDU MaxCmdSN is less than the PDU > ExpCmdSN ...., > they are both ignored". Is this considered an invalid response from the > target?. What happens when the target queuing capacity reaches 0. For > example: target received and processed cmdsn N, but can not receive cmdsn > N+1 yet. In the response for N, target puts N+1 for > expectedCmdSN. How does > it inform the initiator that its window is closed?. Setting MaxCmdSN to N > will be ignored if I understand the above paragraph correctly. > > -Ayman > > From owner-ips@ece.cmu.edu Mon Jun 11 21:19:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21623 for ; Mon, 11 Jun 2001 21:19:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BMwtD11327 for ips-outgoing; Mon, 11 Jun 2001 18:58:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BMwsg11323 for ; Mon, 11 Jun 2001 18:58:54 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 18:57:54 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0708015660@corpmx9.isus.emc.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: iSCSI: statement on mandatory/optional Date: Mon, 11 Jun 2001 18:58:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk While I agree with the intent of the proposed explanatory text, I don't thing the wording is a good idea. To start with, the appropriate words to express levels of requirements are MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, and their synonyms as defined in RFC 2119. The usual practice is to have the RFC-2119 words that express the level of requirement be located near the description of the feature and/or behavior that is required - this simplifies things for the reader. A summary at the end of a section or subsection may be a useful way to structure things to ensure that nothing's been missed. As a result, the following text is not needed: > - All the features that are specified in this draft are > mandatory to implement and mandatory to use, unless otherwise > stated. The rest of the proposed text appears to be about negotiation (implicit or explicit). > - Features that are identified as "mandatory to implement > but optional to use" (like the digests) MUST be implemented > and MUST be honored by one side when the other side uses > them (as in a PDU type), or wants to use them (as in negotiation). The right thing to do here is for each such feature, spell out exactly what the REQUIRED (MUST) or RECOMMENDED (SHOULD) behavior is. The PDU type is easy - one side just sends it and since support for it is REQUIRED, the other side has to do what the specification REQUIRES. For negotiation, the behavior would need to be spelled out in the appropriate place (probably with the feature description, and possibly also with the text tag description). What Mallikarjun proposes above uses negotiation as an announcement mechanism (one side uses negotiation only to tell the other side "I'm doing "). That's definitely an acceptable possibility, but may not be appropriate in all cases. > - Features that are identified as "optional to implement" > (like the synch and steering layer) imply that implementations > that support the features MUST interoperate with other > implementations that do not support these features (i.e. > implementations are guaranteed to be interoperable regardless > of the feature support). Again this principle is generally implicit in the IETF dictum of "be conservative in what you send, liberal in what you accept". For features where this matters (there's risk of a receiver being confused by a sender making a different implementation choice), one possibility is to make support OPTIONAL for the sender and REQUIRED by the receiver (which is the previous case), another is to make it negotiable and REQUIRE support for "not implemented" as well as the behavior behavior to negotiate it. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Thursday, June 07, 2001 1:44 PM > To: ips@ece.cmu.edu > Subject: iSCSI: statement on mandatory/optional > > Julian, > > I suggest the following explanatory text to be added to > the iSCSI main draft (possibly as section 1.2.1). I really > think this (in an abstract sense) helps readers to understand > the optionality or otherwise of iSCSI features. > > Mandatory and optional features > > - All the features that are specified in this draft are > mandatory to implement and mandatory to use, unless otherwise > stated. > - Features that are identified as "mandatory to implement > but optional to use" (like the digests) MUST be implemented > and MUST be honored by one side when the other side uses > them (as in a PDU type), or wants to use them (as in negotiation). > - Features that are identified as "optional to implement" > (like the synch and steering layer) imply that implementations > that support the features MUST interoperate with other > implementations that do not support these features (i.e. > implementations are guaranteed to be interoperable regardless > of the feature support). > > Regards. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > From owner-ips@ece.cmu.edu Mon Jun 11 21:20:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21638 for ; Mon, 11 Jun 2001 21:20:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5C0Ot416646 for ips-outgoing; Mon, 11 Jun 2001 20:24:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [128.221.10.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5C0Osg16641 for ; Mon, 11 Jun 2001 20:24:54 -0400 (EDT) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 20:24:48 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0708015664@corpmx9.isus.emc.com> From: Black_David@emc.com To: jtseng@NishanSystems.com, ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Mon, 11 Jun 2001 20:24:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > Before you or anyone calls consensus, I would like to see > how SLP can solve the following issues: Some of this was covered in: http://ips.pdl.cs.cmu.edu/mail/msg04812.html So, some short answers here ... > 1) Management of Discovery Domains. You don't want > incompatible file systems discovering each other, or > very bad things will happen. Say 'goodbye' to the Unix > file system who's host is discovered by SLP.... Management at the DHCP server of which SLP scope(s) each system gets configured with. > 2) Transfer of X.509 digital certificates. SLP cannot > easily transfer binary entities. This affects the iSCSI > target device's ability to enforce its access control list. I'm not sure that having yet another protocol and server involved in security administration is a "feature", let alone a "requirement". 3) Monitoring of available devices. SLP relies upon service agents re-registering periodically, in order to keep the freshness of its database entries. But this leads to a dilemma: if SA's re-register too often, the DA will be overwhelmed. And if they register not often enough, then you will have stale device entries. The fact is, SLP was not designed to be a real-time discovery protocol. But in storage networks, real-time information is crucial, as even slightly out-of-date information can lead to unnecessary logins and other events that will seriously degrade the performance of the storage network. These time periods are measured in minutes, which doesn't sound like a scaling issue. I'm sceptical that this is actually a problem in practice, as something doing failover (e.g., cluster software) will tend to have its own mechanism to detect failure (e.g., what if the storage fails, but the controller is still happily responding to iSNS polls?). 4) State Change Notifications. This is important to support failover and redundancy capabilities, and to ensure that initiators can persistently maintain their sessions with targets in the event of network topology changes. On this one, Josh is correct, especially about discovery of new targets. More and more OS's can cope with this happening after boot, and I believe HP-UX is among them ;-). Being able to hook up a new target and have it automatically discovered by the corresponding initiators could be very useful. This is for further discussion. Comments?, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jun 11 21:20:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21649 for ; Mon, 11 Jun 2001 21:20:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BNTeH13179 for ips-outgoing; Mon, 11 Jun 2001 19:29:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BNTdg13175 for ; Mon, 11 Jun 2001 19:29:39 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 19:31:21 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0708015661@corpmx9.isus.emc.com> From: Black_David@emc.com To: jtoigo@IntNet.net, ips@ece.cmu.edu Subject: RE: Standards Docs Date: Mon, 11 Jun 2001 19:29:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk In general, the latest versions of all draft documents in the WG are linked to : http://www.ietf.org/html.charters/ips-charter.html --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Jon William Toigo [SMTP:jtoigo@IntNet.net] > Sent: Friday, June 08, 2001 4:54 PM > To: ips@ece.cmu.edu > Subject: Standards Docs > > I am searching for docs related to development efforts in FCIP, iFCP and > iSCSI. Found FCIP and iSCSI at the Carnegie Mellon site: > > (http://www.ece.cmu.edu/~ips/Docs/docs.html) > > However, the iFCP links do not appear to be working. Anyone know where to > get good info on iFCP (and more on FCIP)? > > I would be most appreciative. > > Jon William Toigo > Independent Consultant and Author > jtoigo@intnet.net > From owner-ips@ece.cmu.edu Mon Jun 11 21:25:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21677 for ; Mon, 11 Jun 2001 21:25:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BNfCl13875 for ips-outgoing; Mon, 11 Jun 2001 19:41:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BNfBg13871 for ; Mon, 11 Jun 2001 19:41:11 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel2.hp.com (Postfix) with ESMTP id 052E968F for ; Mon, 11 Jun 2001 19:41:11 -0400 (EDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 8FC3A1F502 for ; Mon, 11 Jun 2001 19:40:43 -0400 (EDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 16:41:09 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A090EA@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" Subject: RE: iSCSI: Wrapping up SendTargets Date: Mon, 11 Jun 2001 16:41:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Josh, > Before you or anyone calls consensus, I would like to see > how SLP can solve the following issues: > > 1) Management of Discovery Domains. You don't want > incompatible file systems discovering each other, or > very bad things will happen. Say 'goodbye' to the Unix > file system who's host is discovered by SLP.... This function is the domain of an application value-add, and does not need to be specified in the SLP protocol. It is perfectly feasible for an application that provides storage discovery services using SLP to filter the information given to a particular initiator based on that initiator's identity (just as a target would when responding to SendTargets). The 'management of discovery domains' is a 'storage network management' related value-add feature of an application, not something SLP must specify. > 2) Transfer of X.509 digital certificates. SLP cannot > easily transfer binary entities. This affects the iSCSI > target device's ability to enforce its access control list. Again, this may be an application value-add, it's not a requirement for storage discovery. Security infrastructure is painful to administer. Seems to me as if a user would chose a generic security solution using something like SCEP protocol, which would work for a variety of applications, not just storage. > 3) Monitoring of available devices. SLP relies upon > service agents re-registering periodically, in order to keep > the freshness of its database entries. But this leads to a > dilemma: if SA's re-register too often, the DA will be > overwhelmed. And if they register not often enough, then > you will have stale device entries. The fact is, SLP was > not designed to be a real-time discovery protocol. But in > storage networks, real-time information is crucial, as even > slightly out-of-date information can lead to unnecessary > logins and other events that will seriously degrade the > performance of the storage network. I'm not sure I see the need for storage devices to "re-register" themselves frequently since storage is not typically a highly dynamic configuration environment. You've made some statements about the real-time needs of storage, but without specific examples I don't see how "real-time monitoring" is a crucial requirement of a centralized storage resource management service. As for your concerns about SA's re-registering too often and overwhelming the DA, this "push" model is viewed as having less problems than the "poll" model where a centralized application requests status updates from multiple devices (but there are tradeoffs with both models). This is a classic networked device monitoring problem, I don't think the group that developed SLP would have ignored it in their protocol service design. > 4) State Change Notifications. This is important to > support failover and redundancy capabilities, and to > ensure that initiators can persistently maintain their > sessions with targets in the event of network topology > changes. This area of service really applies much more to a Fibre Channel domain than an IP/iSCSI domain, due to differences in protocols. Initiators shouldn't need notification of target devices "going away", since the TCP connection provides that information. As for devices being added, there are a number of ways to model this, that's another thread of discussion. On first thought, a model where an administrator triggers the update of initiators when a target is added, rather than some automatic or polled environment seems more desirable to me. How many OS's can deal with storage suddenly "appearing" after initial boot? It seems that SLP could be used by an application to provide this service if it's deemed necessary, it remains to be specified "how". > Furthermore, it would be helpful if you clarify whether your > statements are representing the iSCSI NDT or only of your > personal views. I do not believe your statements regarding > the SLP approach for iSCSI are consistent with what was > agreed to in the NDT. I believe the consensus was that both > iSNS and SLP are to be considered for discovery. > > > Future - Pursue SLP as the "standard discovery", allowing for > > other solutions such as iSNS as appropriate. > > As an NDT member, I cannot support a decision on making any > protocol the "standard" without fully addressing the above > technical issues. The devil is in the details, and only after > exploring such issues will we be able to avoid future pitfalls > that may threaten the timely adoption of iSCSI. I can't speak for Mark, but I think his intent may have been to express that it remains to be fully specified "how" SLP can provide the same information as "SendTargets" (we discussed this in the N&D team mtg). Perhaps he didn't mean to imply that it would be the only way to discover storage. I would speculate that the group/IPS community as a whole has been focused on minimal protocol connectivity, and mostly not had time/bandwidth to weigh in on the greater "storage directory server" requirements. Nishan has done some good work on the iSNS application, the rest of us need to catch up on considering which of it's features are "requirements of a generic storage directory server" and which are value-add. Marjorie Krueger Hewlett-Packard From owner-ips@ece.cmu.edu Mon Jun 11 21:25:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21689 for ; Mon, 11 Jun 2001 21:25:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BNmnU14402 for ips-outgoing; Mon, 11 Jun 2001 19:48:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BHcng17219 for ; Mon, 11 Jun 2001 13:38:50 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id TAA303446 for ; Mon, 11 Jun 2001 19:38:43 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5BHcg0112830 for ; Mon, 11 Jun 2001 19:38:42 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A68.0060CBB4 ; Mon, 11 Jun 2001 19:37:16 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Mon, 11 Jun 2001 20:40:15 +0300 Subject: Re: iSCSI: Response codes in SCSI Response Command Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Unfortunately there is no such standard and every OS has it's own way of handling response codes. Julo "Sanjeev Bhagat (TRIPACE/Zoetermeer)" on 11-06-2001 19:10:26 Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: Julian Satran/Haifa/IBM@IBMIL, "'ISCSI'" , "'Mark Bakke'" , "'Ralph Weber'" cc: Subject: iSCSI: Response codes in SCSI Response Command Current definition states 2.4.2 Status/Response The Status field is used to report the SCSI status of the command (as specified in [SAM2]). The Response is used to report a Service Response. The exact mapping of the iSCSI response codes to SAM service response symbols is outside the scope of this document. If a SCSI device error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set) the target MUST wait until it receives the a data PDU with the F bit set before sending the Response PDU. Valid iSCSI Response codes are: 0x01 - Target Failure 0x02 - Delivery Subsystem Failure 0x03 - Unsolicited data rejected 0x04 - SNACK rejected 0x80-0xff - Reserved for Vendor-Unique Responses DONT YOU THINK that these response codes be actually mapped in SAM document and be made as standard to be followed by any protocol. So iSCSI should also report the same responses as defined in SAM document. Regards, Sanjeev - att1.htm From owner-ips@ece.cmu.edu Mon Jun 11 21:28:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21726 for ; Mon, 11 Jun 2001 21:28:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5BNmjl14394 for ips-outgoing; Mon, 11 Jun 2001 19:48:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5BHa4g16997 for ; Mon, 11 Jun 2001 13:36:04 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA157490 for ; Mon, 11 Jun 2001 19:35:57 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5BHYar133156 for ; Mon, 11 Jun 2001 19:34:36 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A68.00608BDB ; Mon, 11 Jun 2001 19:34:32 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Mon, 11 Jun 2001 20:37:31 +0300 Subject: Re: iSCSI:- SCSI response Flags Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk thanks - julo "Sanjeev Bhagat (TRIPACE/Zoetermeer)" on 11-06-2001 18:14:03 Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: Julian Satran/Haifa/IBM@IBMIL, "'ISCSI'" cc: Subject: iSCSI:- SCSI response Flags there is some mistake in definition of flags byte in SCSI Response Current definition says b3 (u) same as b0 but for the read-part of a bi-directional operation b4 (o) same as b1 but for the read-part of a bi-directional operation it should be b3 (u) same as b1 but for the read-part of a bi-directional operation b4 (o) same as b2 but for the read-part of a bi-directional operation Also the line Bits O and U are mutually exclusive and so are bits o and u. For a response (S=0) b0-b3 MUST be 0. should change to Bits O and U are mutually exclusive and so are bits o and u. For a response (S=0) b1-b4 MUST be 0. or Bits O and U are mutually exclusive and so are bits o and u. For a response (S=0) b0-b4 MUST be 0. Regards, Sanjeev - att1.htm From owner-ips@ece.cmu.edu Mon Jun 11 23:40:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24662 for ; Mon, 11 Jun 2001 23:40:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5C21dH22661 for ips-outgoing; Mon, 11 Jun 2001 22:01:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5C21bg22654 for ; Mon, 11 Jun 2001 22:01:37 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 19:01:32 -0700 Message-ID: From: Joshua Tseng To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Mon, 11 Jun 2001 19:01:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk David, > > > Before you or anyone calls consensus, I would like to see > > how SLP can solve the following issues: > > Some of this was covered in: > > http://ips.pdl.cs.cmu.edu/mail/msg04812.html > > So, some short answers here ... > > > 1) Management of Discovery Domains. You don't want > > incompatible file systems discovering each other, or > > very bad things will happen. Say 'goodbye' to the Unix > > file system who's host is discovered by SLP.... > > Management at the DHCP server of which SLP > scope(s) each system gets configured with. This is still manual configuration of SLP scopes. In the DHCP server, you would configure lists of MAC addresses of DHCP clients with the DHCP option (containing the SLP scope) to be assigned to that client. So let's run through a summary of this process: 1) Create list of iSCSI devices (identified by iSCSI name) you want to include in a particular scope. 2) Figure out the 6-byte MAC address for each of those devices. 3) Enter each MAC address into a list in the DHCP configuration file, along with a name for that scope to be sent as an option. 4) Do the same thing for every other scope. 5) Pray that you don't accidentally place the a MAC address into the wrong list (e.g., your NT initiator into the list containing your Unix file system hosts). > > > 2) Transfer of X.509 digital certificates. SLP cannot > > easily transfer binary entities. This affects the iSCSI > > target device's ability to enforce its access control list. > > I'm not sure that having yet another protocol > and server involved in security administration > is a "feature", let alone a "requirement". As I mentioned in my message to Jim, the ability to configure discovery domains and set up the security policies in a single step, using one tool, would be useful IMO. The alternative is to configure your DHCP server (see above). Then independently configure your SRP for iSCSI. Josh > > 3) Monitoring of available devices. SLP relies upon > service agents re-registering periodically, in order to keep > the freshness of its database entries. But this leads to a > dilemma: if SA's re-register too often, the DA will be > overwhelmed. And if they register not often enough, then > you will have stale device entries. The fact is, SLP was > not designed to be a real-time discovery protocol. But in > storage networks, real-time information is crucial, as even > slightly out-of-date information can lead to unnecessary > logins and other events that will seriously degrade the > performance of the storage network. > > These time periods are measured in minutes, > which doesn't sound like a scaling issue. > I'm sceptical that this is actually a problem > in practice, as something doing failover > (e.g., cluster software) will tend to have > its own mechanism to detect failure (e.g., > what if the storage fails, but the controller > is still happily responding to iSNS polls?). > > 4) State Change Notifications. This is important to > support failover and redundancy capabilities, and to > ensure that initiators can persistently maintain their > sessions with targets in the event of network topology > changes. > > On this one, Josh is correct, especially about > discovery of new targets. More and more OS's > can cope with this happening after boot, and > I believe HP-UX is among them ;-). Being > able to hook up a new target and have it > automatically discovered by the corresponding > initiators could be very useful. > > This is for further discussion. > > Comments?, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Mon Jun 11 23:42:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24678 for ; Mon, 11 Jun 2001 23:42:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5C1Ytm21023 for ips-outgoing; Mon, 11 Jun 2001 21:34:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5C1Yrg21018 for ; Mon, 11 Jun 2001 21:34:53 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 18:34:48 -0700 Message-ID: From: Joshua Tseng To: "'Jim Hafner'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Mon, 11 Jun 2001 18:34:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Jim, > > Josh, > > There is a fundamental difference of purpose behind SLPs and > iSNS's. The > things you list below as missing from SLP are *not* discovery > functions but > go well beyond that into more complex management. I believe most if not all of the issues I listed are fully or partially discovery issues. But regardless of whether they are strictly "discovery" issues or not, they are issues that need to be addressed somehow. The question I have is do you want separate tools to do discovery and management, or would it be easier to have all discovery and management issues addressed with one integrated protocol? SLP would result in a patchwork of multiple unrelated and uncoordinated tools and protocols to do discovery, management, and monitoring of storage devices. I think this would be a setback for iSCSI. iSNS is no more difficult to implement than SLP. For the same amount of effort to implement SLP, you could have iSNS and all the management capabilities and real-time monitoring of devices. So why would we "standardize" on SLP if additional protocols will be needed to deliver essential management functions? > > The purpose of the Naming and Discovery Team's effort is to define > discovery: in short how does an initiator "walk the bus". We are not > charged with full complex management issues. When scoped in > this way, SLP > seems perfectly suitable for discovery. IMO, a critical part of the discovery problem is how you manage the discovery capability, and whether you can manage the scope of the discovery process. SLP does not have this capability; scopes must be managed manually. This includes the DHCP approach for managing SLP scopes--MAC addresses (not iSCSI Names) must be manually mapped to a scope, and this mapping is stored as a series of MAC address listings in the DHCP server. (thanks, Glen Turner for pointing that out) > Before you or anyone calls consensus, I would like to see > how SLP can solve the following issues: > > 1) Management of Discovery Domains. You don't want > incompatible file systems discovering each other, or > very bad things will happen. Say 'goodbye' to the Unix > file system who's host is discovered by SLP.... > > > Discovery does not constitute a major exposure; discovery only lets an > initiator know that something exists. The full security > context of login > is still there as the major barrior to authentication and > authorization. > So the integrity problem you speak of isn't there (in iSCSI, > though it is > there in FCP). > SLP has nothing to say about security and managing the context of login. So security and login configuration would have to be manual or through some other mechanism. Since we are relying on SRP authentication, the administrator is only an accidental password mis-entry away from losing his Unix file system. I don't know about you, but this makes me nervous. And it would also take away the option of turning off the iSCSI authentication mechanism (something they might want to do if they are in simple network with few devices and no security concerns). Security is meant to protect against deliberate attacks; it does nothing to prevent against accidental mis-configurations. The threat here is accidental mixing of NT and Unix file systems, and we should not be relying on the login process to protect against this. This goes without mentioning the wasted logins that will take place even if the administrator is fortunate enough to avoid mistakes in setting up his security and access control policies. > > > 2) Transfer of X.509 digital certificates. SLP cannot > easily transfer binary entities. This affects the iSCSI > target device's ability to enforce its access control list. > > > How so? Again, the SLP is only used to find the existence of > the device. > The iSCSI login does the hard part of enforcement and that > happens on a > completely different connection with a completely different > protocol from > SLP discovery. SLP isn't going to be used for the target to > get its access > control list (as you want iSNS to do). Configuration of > those lists is NOT > a discovery function and can be handled by direct management > functions on > the target. This may not be the cleanest way, but it is > functional (it's > what people are doing today in more contexts that just iSCSI). > The ability to transfer X.509 certificates would be a nice-to-have capability that I would hope the "standard" discovery protocol would be able to do. No, it's not absolutely essential to set up the security context, but public key-based authentication would significantly cut down the amount of configuration needed to set up the security. iSNS does this by allowing the security setup to piggyback on the discovery setup. Josh > > 3) Monitoring of available devices. SLP relies upon > service agents re-registering periodically, in order to keep > the freshness of its database entries. But this leads to a > dilemma: if SA's re-register too often, the DA will be > overwhelmed. And if they register not often enough, then > you will have stale device entries. The fact is, SLP was > not designed to be a real-time discovery protocol. But in > storage networks, real-time information is crucial, as even > slightly out-of-date information can lead to unnecessary > logins and other events that will seriously degrade the > performance of the storage network. > > > I don't see this as a major problem either. Discovery and > login should > happen relatively infrequently in a storage network (e.g., at > boot time or > "rescan" time). Slightly stale information is probably not a > major problem > and will almost certainly only affect a limited number of systems. > > > 4) State Change Notifications. This is important to > support failover and redundancy capabilities, and to > ensure that initiators can persistently maintain their > sessions with targets in the event of network topology > changes. > > > > > > Now - Keep SendTargets, document it in the iSCSI spec, and > > declare its limitation to just what is needed to > > connect to a target (name, address, aggregation). > > > > Define ReportPortalGroups functionality as a subset > > of SendTargets. > > I understand you'll be out of contact for the next 1.5 weeks, > and so you must be in a rush, but I must ask that you give us a > at least a few days or so to digest the 10+ messages on this > subject. I personally have been in-and-out of the office for the > past couple days and haven't been able to respond till now. > > Once again, I support John's proposal to move Sendtargets to > the annex. I don't think Sendtargets should be in the main > document. > > Furthermore, it would be helpful if you clarify whether your > statements are representing the iSCSI NDT or only of your > personal views. I do not believe your statements regarding > the SLP approach for iSCSI are consistent with what was > agreed to in the NDT. I believe the consensus was that both > iSNS and SLP are to be considered for discovery. > > > Future - Pursue SLP as the "standard discovery", allowing for > > other solutions such as iSNS as appropriate. > > As an NDT member, I cannot support a decision on making any > protocol the "standard" without fully addressing the above > technical issues. The devil is in the details, and only after > exploring such issues will we be able to avoid future pitfalls > that may threaten the timely adoption of iSCSI. > > Josh > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Friday, June 08, 2001 1:31 PM > > To: IPS > > Subject: iSCSI: Wrapping up SendTargets > > > > > > > > Dear Discovery Enthusiasts- > > > > The SendTargets threads are winding down, so I would like > > to see if we have a rough consensus on a few things. > > > > > > I've read through all of the threads on whether to > > keep SendTargets in iSCSI, and I believe there is > > a rough concensus that we should keep it in, carefully > > limit its growth, and recommend that functionality > > beyond the basic reporting of the targets and addresses > > available be implemented using standard discovery > > protocols instead. On looking through responses from > > Josh, Steph, Larry, Paul, Julian, Mallikarjun, John, > > Kaladhar, Jim, and Marjorie, I have seen 7 (I include > > myself in this count) in favor of keeping SendTargets > > but limiting its growth, one in favor of dropping > > SendTargets, and three with no comment on SendTargets. > > > > For adding discovery functionality beyond basic reporting > > of available targets and addresses, I have seen 5 > > (again, including myself) in favor of using SLP for > > future discovery, one in favor of using iSNS for future > > discovery, two in favor of either SLP or iSNS, and > > three with no comment. > > > > I realize that this doesn't constitute calling consensus, > > and I'm not the person to do it, but I wanted to point out > > where most people who have responded seem to be headed, > > so that others who wish to be heard are motivated to > > comment. > > > > > > Anyway, that said, I would like to see SendTargets stay > > in the draft, mainly for the same reasons that several > > others already stated: > > > > SendTargets shares the same authentication as iSCSI. > > > > SendTargets provides a simple, low-risk path to building > > interoperable, minimal-configuration iSCSI implementations. > > > > SendTargets builds on the existing iSCSI login and text > > commands, and will be the smallest-footprint and -effort > > way to implement this basic functionality. > > > > The first reason given above is the most important. > > > > I believe that we should limit extensions to it as much as > > possible, for instance, we should not attempt to return > > certificates and other information. Implementations that > > wish to do fancier things like these would implement one > > of the other discovery mechanisms. We could go as far > > as atrophying SendTargets later, but I think that John is > > right, that it would be a decision to be made later (iSCSIv2). > > > > That said, I do agree that Julian is correct from a philosophical > > point of view; discovery really belongs outside the protocol. > > This is a direction we need to pursue. I absolutely agree with > > Julian that we have to be careful not to let something like > > SendTargets turn into a management protocol. It would be "easy > > to do" :-). > > > > I see a mild consensus toward SLP as a good direction for > > moving forward with discovery beyond simple target reporting. > > The SLP folks themselves intended for hosts to be able to > > behave in the Unicast manner we are trying, and are interested > > in updating the SLP API to handle this. However, I think that > > it would be best to use SendTargets for now, while we both > > make sure that the right SLP API is developed, and that we > > can solve the problem of authentication schemes. > > > > > > On ReportPortalGroups > > > > I did not hear anyone say we didn't need this functionality; most > > seemed to say the we either "at least" need ReportPortalGroups > > if we don't have SendTargets, or that SendTargets was assumed, > > and ReportPortalGroups is a subset. > > > > I agree that this is necessary functionality, but that if we > > can assume that we still have SendTargets, ReportPortalGroups > > is really a subset. Paul mentioned just using: > > > > SendTargets > > > > would be the same as ReportPortalGroups. This might help > > avoid the feature creep that some of the responders feared. > > > > Anyway, either way of doing ReportPortalGroups (making it its > > own command or making it part of SendTargets) is fine with me. > > I think that the consensus was that as long as we have SendTargets, > > we should use it for the ReportPortalGroups functionality. > > > > > > On the Growth of SendTargets > > > > A few people mentioned concern about TargetAlias and digital > > certificates. TargetAlias is returned by the target upon login > > anyway, so I could live with removing it from SendTargets, and > > letting the higher-level discovery/management mechanisms deal > > with it. I think that the same goes for certificates. As we > > figure out how our customers really want to do security for iSCSI, > > we may have other mechanisms in place for handling these. > > > > This should help keep SendTargets from growing. Stating that > > it is limited to name, address, and aggregation information (just > > what is required to connect) should keep it right where it is, > > and the future discovery mechanisms can take over from there. > > > > So here's what I think we have: > > > > Now - Keep SendTargets, document it in the iSCSI spec, and > > declare its limitation to just what is needed to > > connect to a target (name, address, aggregation). > > > > Define ReportPortalGroups functionality as a subset > > of SendTargets. > > > > Future - Pursue SLP as the "standard discovery", allowing for > > other solutions such as iSNS as appropriate. > > > > Do we have rough consensus on either of the above, at least > > on the "Now" part? > > > > Once we have consensus on that, we can continue the threads > > on aggregation tags, which targets should provide SendTargets, > > and whether or not we need iterators. > > > > Anyway, I have to apologize in advance; I will be out of > > the office until the 18th, so I am sort of throwing this out > > on the list and running away. > > > > > > Regards, > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > > > > From owner-ips@ece.cmu.edu Tue Jun 12 12:24:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18663 for ; Tue, 12 Jun 2001 12:24:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5CEcSg18536 for ips-outgoing; Tue, 12 Jun 2001 10:38:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5CEcOg18508 for ; Tue, 12 Jun 2001 10:38:25 -0400 (EDT) Received: from quasit.br.itc.hp.com (quasit.br.itc.hp.com [15.145.8.135]) by bramg1.net.external.hp.com (Postfix) with ESMTP id 4FF6FFC for ; Tue, 12 Jun 2001 16:38:23 +0200 (METDST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by quasit.br.itc.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id PAA19597 for ; Tue, 12 Jun 2001 15:38:22 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Tue, 12 Jun 2001 15:38:22 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 15:38:22 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC101E7A74D@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: RE: Task Management Commands and Immediate Delivery. Date: Tue, 12 Jun 2001 15:38:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Charles, Comments within text: Matthew -----Original Message----- From: Binford, Charles [mailto:CBinford@Pirus.com] Sent: Tuesday, June 12, 2001 2:50 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'; 'ips@ece.cmu.edu' Subject: RE: Task Management Commands and Immediate Delivery. Matthew, In the portion of text I copied from your attachment, step b) claims to know that the removed entries had been aborted by the target in the target's iSCSI layer. ---------------------------------- At the initiator when updating ExpCmdSN: a) if the "barrier list" is empty or ExpCmdSN is less than the CmdSN of the oldest item in the barrier list then skip to step d b) remove the oldest barrier list item, and remove and silently discard all entries marked for cleanup having a CmdSN field less than ExpCmdSN. These entries have been aborted by the target while they were in the target's iSCSI layer. ----------------------------------- I don't see how the initiator can know that. Consider the following scenario: Imitator Target CmdSn 8 ---> -_ --> CmdSn 9 ---> -_ <-- expCmd 9 --> CmdSn 10 ---> -_ <-- expCmd 10 --> Abort (imm)--> -_ <-- expCmd 11 --> Assume at that at the time the Abort was sent, the expCmd 9 had not yet arrived (hard to show in ASCII drawings!) When the initiator sent the abort, he created the barrier list of Cmdsn 8-10. When expCmd 9 arrives at the initiator, the processing will take him to step b) above and remove that task associated with CmdSn 8. However, since the Abort had not yet arrived at that target when the target sent expCmd 9, CmdSn 8 was certainly not aborted by the target's iSCSI layer. I've been trying to figure out if the offending sentence is merely an non-significant, incorrect statement on what happens or if it is a hole in the algorithm. On the other hand, maybe the statement and algorithm are correct and I miss-understood something. Also, this algorithm has an unspoken assumption that only task management functions will be delivered with the immediate option. Don't things break down if an initiator chooses to send normal SCSI I/O with immediate? Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Monday, June 11, 2001 12:08 PM To: 'ips@ece.cmu.edu' Subject: Task Management Commands and Immediate Delivery. We have been working through section 7.3 and were unclear on a few areas. Essentially, the algorithm is fine but we felt that there were are number of areas that either need clarifying or expanding. Attached is an 'updated' version of the section that addresses the issues. The algorithm relies on both the initiator and target performing the exact same action to remove items off of the command queues otherwise there could be either a discrepancy between the two sides. Another alternative is for the target to inform the initiator of those commands that have been aborted in the iSCSI layer (but not the SCSI layer). In which case there is no need to implement the algorithm in the initiator. Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Tue Jun 12 12:24:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18681 for ; Tue, 12 Jun 2001 12:24:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5CEuj819936 for ips-outgoing; Tue, 12 Jun 2001 10:56:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from apollo.pirus.com ([63.91.118.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5CEuhg19929 for ; Tue, 12 Jun 2001 10:56:43 -0400 (EDT) Received: by apollo.pirus.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 11:00:14 -0400 Message-ID: From: "Binford, Charles" To: "'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'" , "'ips@ece.cmu.edu'" Subject: RE: Task Management Commands and Immediate Delivery. Date: Tue, 12 Jun 2001 11:00:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Thanks, I had missed the fact that the barrier list was only Task Management commands. The algorithm works much better with that understanding! (next time I'll read a little closer...) Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Tuesday, June 12, 2001 9:21 AM To: 'Binford, Charles' Subject: RE: Task Management Commands and Immediate Delivery. Hi Charles, Comments within text: Matthew -----Original Message----- From: Binford, Charles [mailto:CBinford@Pirus.com] Sent: Tuesday, June 12, 2001 2:50 PM To: 'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'; 'ips@ece.cmu.edu' Subject: RE: Task Management Commands and Immediate Delivery. Matthew, In the portion of text I copied from your attachment, step b) claims to know that the removed entries had been aborted by the target in the target's iSCSI layer. ---------------------------------- At the initiator when updating ExpCmdSN: a) if the "barrier list" is empty or ExpCmdSN is less than the CmdSN of the oldest item in the barrier list then skip to step d b) remove the oldest barrier list item, and remove and silently discard all entries marked for cleanup having a CmdSN field less than ExpCmdSN. These entries have been aborted by the target while they were in the target's iSCSI layer. ----------------------------------- I don't see how the initiator can know that. Consider the following scenario: Imitator Target CmdSn 8 ---> -_ --> CmdSn 9 ---> -_ <-- expCmd 9 --> CmdSn 10 ---> -_ <-- expCmd 10 --> Abort (imm)--> -_ <-- expCmd 11 --> ***Matthew: The abort will have the CmdSN field set to 11 (to mark its position). Assume at that at the time the Abort was sent, the expCmd 9 had not yet arrived (hard to show in ASCII drawings!) When the initiator sent the abort, he created the barrier list of Cmdsn 8-10. ***Matthew: The barrier list contains only the TM commands. In your example the barrier list will contain the immediate command (e.g. CmdSN=11). The commands (and placeholders) are marked for candidacy. When expCmd 9 arrives at the initiator, the processing will take him to step b) above and remove that task associated with CmdSn 8. However, since the Abort had not yet arrived at that target when the target sent expCmd 9, CmdSn 8 was certainly not aborted by the target's iSCSI layer. ***Matthew: You are right. In this example CmdSN has been delivered to the SCSI layer (within the target) and that resulted in the ExpCmdSN being incremented. The TM command must be passed to the SCSI layer and it is the SCSI layer that would abort CmdSN=8. I've been trying to figure out if the offending sentence is merely an non-significant, incorrect statement on what happens or if it is a hole in the algorithm. On the other hand, maybe the statement and algorithm are correct and I miss-understood something. Also, this algorithm has an unspoken assumption that only task management functions will be delivered with the immediate option. Don't things break down if an initiator chooses to send normal SCSI I/O with immediate? ***Matthew: The Task Management commands are the only ones that effect other commands and hence the reason for this algorithm. Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Monday, June 11, 2001 12:08 PM To: 'ips@ece.cmu.edu' Subject: Task Management Commands and Immediate Delivery. We have been working through section 7.3 and were unclear on a few areas. Essentially, the algorithm is fine but we felt that there were are number of areas that either need clarifying or expanding. Attached is an 'updated' version of the section that addresses the issues. The algorithm relies on both the initiator and target performing the exact same action to remove items off of the command queues otherwise there could be either a discrepancy between the two sides. Another alternative is for the target to inform the initiator of those commands that have been aborted in the iSCSI layer (but not the SCSI layer). In which case there is no need to implement the algorithm in the initiator. Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Tue Jun 12 12:31:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18832 for ; Tue, 12 Jun 2001 12:31:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5CDvcO15373 for ips-outgoing; Tue, 12 Jun 2001 09:57:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from apollo.pirus.com ([63.91.118.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5CDvZg15365 for ; Tue, 12 Jun 2001 09:57:36 -0400 (EDT) Received: by apollo.pirus.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 09:49:51 -0400 Message-ID: From: "Binford, Charles" To: "'BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)'" , "'ips@ece.cmu.edu'" Subject: RE: Task Management Commands and Immediate Delivery. Date: Tue, 12 Jun 2001 09:49:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Matthew, In the portion of text I copied from your attachment, step b) claims to know that the removed entries had been aborted by the target in the target's iSCSI layer. ---------------------------------- At the initiator when updating ExpCmdSN: a) if the "barrier list" is empty or ExpCmdSN is less than the CmdSN of the oldest item in the barrier list then skip to step d b) remove the oldest barrier list item, and remove and silently discard all entries marked for cleanup having a CmdSN field less than ExpCmdSN. These entries have been aborted by the target while they were in the target's iSCSI layer. ----------------------------------- I don't see how the initiator can know that. Consider the following scenario: Imitator Target CmdSn 8 ---> -_ --> CmdSn 9 ---> -_ <-- expCmd 9 --> CmdSn 10 ---> -_ <-- expCmd 10 --> Abort (imm)--> -_ <-- expCmd 11 --> Assume at that at the time the Abort was sent, the expCmd 9 had not yet arrived (hard to show in ASCII drawings!) When the initiator sent the abort, he created the barrier list of Cmdsn 8-10. When expCmd 9 arrives at the initiator, the processing will take him to step b) above and remove that task associated with CmdSn 8. However, since the Abort had not yet arrived at that target when the target sent expCmd 9, CmdSn 8 was certainly not aborted by the target's iSCSI layer. I've been trying to figure out if the offending sentence is merely an non-significant, incorrect statement on what happens or if it is a hole in the algorithm. On the other hand, maybe the statement and algorithm are correct and I miss-understood something. Also, this algorithm has an unspoken assumption that only task management functions will be delivered with the immediate option. Don't things break down if an initiator chooses to send normal SCSI I/O with immediate? Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Monday, June 11, 2001 12:08 PM To: 'ips@ece.cmu.edu' Subject: Task Management Commands and Immediate Delivery. We have been working through section 7.3 and were unclear on a few areas. Essentially, the algorithm is fine but we felt that there were are number of areas that either need clarifying or expanding. Attached is an 'updated' version of the section that addresses the issues. The algorithm relies on both the initiator and target performing the exact same action to remove items off of the command queues otherwise there could be either a discrepancy between the two sides. Another alternative is for the target to inform the initiator of those commands that have been aborted in the iSCSI layer (but not the SCSI layer). In which case there is no need to implement the algorithm in the initiator. Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com From owner-ips@ece.cmu.edu Tue Jun 12 14:39:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22112 for ; Tue, 12 Jun 2001 14:39:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5CGNBF26519 for ips-outgoing; Tue, 12 Jun 2001 12:23:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from apollo.pirus.com ([63.91.118.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5CGN8g26513 for ; Tue, 12 Jun 2001 12:23:08 -0400 (EDT) Received: by apollo.pirus.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 12:26:38 -0400 Message-ID: From: "Binford, Charles" To: "'ips@ece.cmu.edu'" Subject: Unit Attention after Clear Task Set Date: Tue, 12 Jun 2001 12:26:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Sorry if this has already been discussed and decided upon, I looked in the archives but couldn't find the issue being discussed. Rev 6, Section 2.5.1, Clear Task Set. Currently the spec says a target MUST enter Unit Attention for all other attached initiators. This statement is true if the newly defined TAS bit in the Control mode page is 0. However, if the TAS bit is one, then the target is supposed to complete the "aborted" commands to all of the other initiators with a Task Aborted status and not set the unit attention. My question is, is iSCSI specifically prohibiting the setting of the TAS bit, or was this an oversight? The TAS bit was new in Rev 14 of SAM-2 last September. See t10/00-229r3 for details of what changed in SAM and SPC for this new function. Charles Binford Pirus Networks 316.315.0382 x222 From owner-ips@ece.cmu.edu Tue Jun 12 21:33:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27843 for ; Tue, 12 Jun 2001 21:33:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5CNuDv00289 for ips-outgoing; Tue, 12 Jun 2001 19:56:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5CNuCg00284 for ; Tue, 12 Jun 2001 19:56:12 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA103072 for ; Tue, 12 Jun 2001 18:50:43 -0500 Received: from f3n42e (d03nm042h.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5CNuBE289462 for ; Tue, 12 Jun 2001 17:56:11 -0600 Importance: Normal Subject: RE: iSCSI: Wrapping up SendTargets To: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 12 Jun 2001 16:56:10 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/12/2001 04:56:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, I think this thread is wandering off the field. The question is the issue of SendTargets. Let's remind ourselves of the original purpose of this proposed protocol: namely, it's designed for a storage box that contains one or more iSCSI target devices to report about ITSELF, about what's in it! This includes both a list of the iSCSI targets it has PLUS the session coordination (via tags) of the various IPaddress/tcpport combos it supports. In other words, it's job is to report about itself! The use of (unicast) SLP as an alternative to SendTargets was focused exactly on the same question: I ask a single box to tell me about itself. This function lies between the two extremes of (a) static configuration of initiators and (b) centralized management via iSNS style services. Somehow, someway, we need to define a protocol for a box to "tell us about itself" in the absense of the centralized management infrastructure. That seems critical to me. Even if I want to do static configuration, the guy doing the configuration needs a way to get at the guts of each new box he/she rolls into the environment. The choices are, it seems, that *every* box would need to support at least one of: a) SendTargets b) modified SLP c) iSNS What's the consensus on the protocol we aim for to solve this middle ground discovery problem? Jim Hafner From owner-ips@ece.cmu.edu Tue Jun 12 21:33:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27964 for ; Tue, 12 Jun 2001 21:33:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5CNndc29836 for ips-outgoing; Tue, 12 Jun 2001 19:49:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5CNnbg29830 for ; Tue, 12 Jun 2001 19:49:38 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 16:49:32 -0700 Message-ID: From: Charles Monia To: "'ips@ece.cmu.edu'" Subject: RE: Unit Attention after Clear Task Set Date: Tue, 12 Jun 2001 16:49:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi: The referenced section seems to overlap and conflict with the requirements specified in SAM-2. Although there may be a valid reason for doing so, it's not self-evident to me. Charles > -----Original Message----- > From: Binford, Charles [mailto:CBinford@pirus.com] > Sent: Tuesday, June 12, 2001 9:27 AM > To: 'ips@ece.cmu.edu' > Subject: Unit Attention after Clear Task Set > > > Julian, Sorry if this has already been discussed and decided > upon, I looked > in the archives but couldn't find the issue being discussed. > > Rev 6, Section 2.5.1, Clear Task Set. Currently the spec > says a target MUST > enter Unit Attention for all other attached initiators. This > statement is > true if the newly defined TAS bit in the Control mode page is > 0. However, > if the TAS bit is one, then the target is supposed to > complete the "aborted" > commands to all of the other initiators with a Task Aborted > status and not > set the unit attention. > > My question is, is iSCSI specifically prohibiting the setting > of the TAS > bit, or was this an oversight? The TAS bit was new in Rev 14 > of SAM-2 last > September. See t10/00-229r3 for details of what changed in > SAM and SPC for > this new function. > > > Charles Binford > Pirus Networks > 316.315.0382 x222 > From owner-ips@ece.cmu.edu Tue Jun 12 21:36:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28746 for ; Tue, 12 Jun 2001 21:36:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5CNUd828613 for ips-outgoing; Tue, 12 Jun 2001 19:30:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5CNUcg28608 for ; Tue, 12 Jun 2001 19:30:38 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 16:30:30 -0700 Message-ID: From: Charles Monia To: "Ips Reflector (E-mail)" Subject: RE: iSCSI: Wrapping up SendTargets Date: Tue, 12 Jun 2001 16:30:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk My .02: We either have a common tool for discovery and SAN management or we have (perhaps) a common discovery tool plus an assortment of ad-hoc 'value-added' solutions to fill the gaps. In my opinion, such an outcome would make it impossible to integrate heterogeneous storage products into the enterprise environment. With that concern in mind, the iSNS authors decided that a single SAN management and discovery protocol was essential. As with iSCSI, we believed the right place to start was with a model that was widely deployed and supported by existing storage management products. As to alternate approaches, I believe it will always be possible to point to this or that tool or protocol that does or can be extended to do some piece of iSNS functionality. What's been missing, however, is a comprehensive, well-articulated model into which all of these fit and a willingness to deploy the implementations so we can all do a test drive. If anyone has an alternative model and implementation, I would encourage them to put both forward for consideration. Charles > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > [mailto:marjorie_krueger@hp.com] > Sent: Monday, June 11, 2001 4:41 PM > To: Ips Reflector (E-mail) > Subject: RE: iSCSI: Wrapping up SendTargets > > > Josh, > > > Before you or anyone calls consensus, I would like to see > > how SLP can solve the following issues: > > > > 1) Management of Discovery Domains. You don't want > > incompatible file systems discovering each other, or > > very bad things will happen. Say 'goodbye' to the Unix > > file system who's host is discovered by SLP.... > > This function is the domain of an application value-add, and > does not need > to be specified in the SLP protocol. It is perfectly feasible for an > application that provides storage discovery services using > SLP to filter the > information given to a particular initiator based on that initiator's > identity (just as a target would when responding to SendTargets). The > 'management of discovery domains' is a 'storage network > management' related > value-add feature of an application, not something SLP must specify. > > > 2) Transfer of X.509 digital certificates. SLP cannot > > easily transfer binary entities. This affects the iSCSI > > target device's ability to enforce its access control list. > > Again, this may be an application value-add, it's not a > requirement for > storage discovery. Security infrastructure is painful to > administer. Seems > to me as if a user would chose a generic security solution > using something > like SCEP protocol, which would work for a variety of > applications, not just > storage. > > > 3) Monitoring of available devices. SLP relies upon > > service agents re-registering periodically, in order to keep > > the freshness of its database entries. But this leads to a > > dilemma: if SA's re-register too often, the DA will be > > overwhelmed. And if they register not often enough, then > > you will have stale device entries. The fact is, SLP was > > not designed to be a real-time discovery protocol. But in > > storage networks, real-time information is crucial, as even > > slightly out-of-date information can lead to unnecessary > > logins and other events that will seriously degrade the > > performance of the storage network. > > I'm not sure I see the need for storage devices to > "re-register" themselves > frequently since storage is not typically a highly dynamic > configuration > environment. You've made some statements about the real-time needs of > storage, but without specific examples I don't see how "real-time > monitoring" is a crucial requirement of a centralized storage resource > management service. > > As for your concerns about SA's re-registering too often and > overwhelming > the DA, this "push" model is viewed as having less problems > than the "poll" > model where a centralized application requests status updates > from multiple > devices (but there are tradeoffs with both models). This is a classic > networked device monitoring problem, I don't think the group > that developed > SLP would have ignored it in their protocol service design. > > > 4) State Change Notifications. This is important to > > support failover and redundancy capabilities, and to > > ensure that initiators can persistently maintain their > > sessions with targets in the event of network topology > > changes. > > This area of service really applies much more to a Fibre > Channel domain than > an IP/iSCSI domain, due to differences in protocols. > Initiators shouldn't > need notification of target devices "going away", since the > TCP connection > provides that information. As for devices being added, there > are a number > of ways to model this, that's another thread of discussion. On first > thought, a model where an administrator triggers the update > of initiators > when a target is added, rather than some automatic or polled > environment > seems more desirable to me. How many OS's can deal with > storage suddenly > "appearing" after initial boot? It seems that SLP could be used by an > application to provide this service if it's deemed necessary, > it remains to > be specified "how". > > > Furthermore, it would be helpful if you clarify whether your > > statements are representing the iSCSI NDT or only of your > > personal views. I do not believe your statements regarding > > the SLP approach for iSCSI are consistent with what was > > agreed to in the NDT. I believe the consensus was that both > > iSNS and SLP are to be considered for discovery. > > > > > Future - Pursue SLP as the "standard discovery", allowing for > > > other solutions such as iSNS as appropriate. > > > > As an NDT member, I cannot support a decision on making any > > protocol the "standard" without fully addressing the above > > technical issues. The devil is in the details, and only after > > exploring such issues will we be able to avoid future pitfalls > > that may threaten the timely adoption of iSCSI. > > I can't speak for Mark, but I think his intent may have been > to express that > it remains to be fully specified "how" SLP can provide the > same information > as "SendTargets" (we discussed this in the N&D team mtg). > Perhaps he didn't > mean to imply that it would be the only way to discover storage. > > I would speculate that the group/IPS community as a whole has > been focused > on minimal protocol connectivity, and mostly not had > time/bandwidth to weigh > in on the greater "storage directory server" requirements. > Nishan has done > some good work on the iSNS application, the rest of us need > to catch up on > considering which of it's features are "requirements of a > generic storage > directory server" and which are value-add. > > Marjorie Krueger > Hewlett-Packard > From owner-ips@ece.cmu.edu Tue Jun 12 23:06:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00614 for ; Tue, 12 Jun 2001 23:06:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5D1HYd05474 for ips-outgoing; Tue, 12 Jun 2001 21:17:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5D1HXg05469 for ; Tue, 12 Jun 2001 21:17:33 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA111326 for ; Tue, 12 Jun 2001 20:12:03 -0500 Received: from f4n49e (d03nm065h.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5D1HVE17036 for ; Tue, 12 Jun 2001 19:17:31 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Wrapping up SendTargets To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 12 Jun 2001 18:08:57 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/12/2001 07:17:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk iSCSI Team, I think that Jim has said it well. I had a proposal about an Annex, for the SendTargets, but whether we do that or not, I am getting the feeling that most folks think, at least for this version of the protocol that we keep SendTargets, and the subset that can be used as a Report Portal Groups. Even Mark, even though he thought he could Hack the SLP Source code to do a similar thing, thought that it was best to keep SendTargets. I would like to propose that we Close on Keeping the SendTargets command, and the subset that is either Report Portal Groups or SendTargets (which returns only the information for that target only). Now as to where we put the command. I suggested an Annex, but can clearly live with it in the Main document. I seemed to get very little support for the idea of the Annex, and since I think that the functions of Report Portal Groups, must be part of the base, I would like to suggest that we either 1) Place the SendTargets in the Annex, and put a Report Portal Groups in the main document, or 2) Keep the Send Targets in the Main Document and add the argument of Please state your positions . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 06/12/2001 04:56:10 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI: Wrapping up SendTargets Folks, I think this thread is wandering off the field. The question is the issue of SendTargets. Let's remind ourselves of the original purpose of this proposed protocol: namely, it's designed for a storage box that contains one or more iSCSI target devices to report about ITSELF, about what's in it! This includes both a list of the iSCSI targets it has PLUS the session coordination (via tags) of the various IPaddress/tcpport combos it supports. In other words, it's job is to report about itself! The use of (unicast) SLP as an alternative to SendTargets was focused exactly on the same question: I ask a single box to tell me about itself. This function lies between the two extremes of (a) static configuration of initiators and (b) centralized management via iSNS style services. Somehow, someway, we need to define a protocol for a box to "tell us about itself" in the absense of the centralized management infrastructure. That seems critical to me. Even if I want to do static configuration, the guy doing the configuration needs a way to get at the guts of each new box he/she rolls into the environment. The choices are, it seems, that *every* box would need to support at least one of: a) SendTargets b) modified SLP c) iSNS What's the consensus on the protocol we aim for to solve this middle ground discovery problem? Jim Hafner From owner-ips@ece.cmu.edu Tue Jun 12 23:07:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00634 for ; Tue, 12 Jun 2001 23:07:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5D21Te08304 for ips-outgoing; Tue, 12 Jun 2001 22:01:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5D21Sg08298 for ; Tue, 12 Jun 2001 22:01:28 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 19:01:22 -0700 Message-ID: From: Joshua Tseng To: "'KRUEGER,MARJORIE (HP-Roseville,ex1)'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Tue, 12 Jun 2001 19:01:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie, > > Josh, > > > Before you or anyone calls consensus, I would like to see > > how SLP can solve the following issues: > > > > 1) Management of Discovery Domains. You don't want > > incompatible file systems discovering each other, or > > very bad things will happen. Say 'goodbye' to the Unix > > file system who's host is discovered by SLP.... > > This function is the domain of an application value-add, and > does not need > to be specified in the SLP protocol. It is perfectly feasible for an > application that provides storage discovery services using > SLP to filter the > information given to a particular initiator based on that initiator's > identity (just as a target would when responding to SendTargets). The > 'management of discovery domains' is a 'storage network > management' related > value-add feature of an application, not something SLP must specify. If this function doesn't need to be specified, then how do you intend to get mixed-vendor environments to deliver this functionality? One vendor supplies the target, a different vendor supplies the initiator, and each vendor decides to implement their own approach for configuring scopes or discovery domains. Without a standard approach that delivers a full, comprehensive set of capabilities (management, monitoring, discovery, etc...), each vendor will implement their own proprietary approach to deliver incremental capabilities required to support their individual iSCSI implementation. There will not be seamless interoperability, which would be a setback for iSCSI. What we will end up with is the "Tower of Babel". I don't really care if you call iSNS an "application" or a "protocol". The point is, in the interest of interoperability, we are proposing iSNS as a standard, comprehensive approach. The operational model has been tested and proven, and it gives you every capability SLP promises, and far more. And we have made the source code available to everyone. Now why anyone would want to ignore all this and write their own proprietary application to fill in feature gaps of SLP, ...well that's their own business... > > > 2) Transfer of X.509 digital certificates. SLP cannot > > easily transfer binary entities. This affects the iSCSI > > target device's ability to enforce its access control list. > > Again, this may be an application value-add, it's not a > requirement for > storage discovery. Security infrastructure is painful to > administer. Seems > to me as if a user would chose a generic security solution > using something > like SCEP protocol, which would work for a variety of > applications, not just > storage. iSNS is not a certificate server; it only provides for distribution of X.509 public key certificates. Strictly speaking, it is not "security infrastructure" any more than an excel spreadsheet is. But iSNS is a useful tool which can be used to store your security policy, and much easier to use than storing your ACL's and certificates on excel spreadsheets. SCEP performs a different role than iSNS. Indeed, iSNS could be deployed alongside the SCEP server to distribute certificates for storage devices. > > > 3) Monitoring of available devices. SLP relies upon > > service agents re-registering periodically, in order to keep > > the freshness of its database entries. But this leads to a > > dilemma: if SA's re-register too often, the DA will be > > overwhelmed. And if they register not often enough, then > > you will have stale device entries. The fact is, SLP was > > not designed to be a real-time discovery protocol. But in > > storage networks, real-time information is crucial, as even > > slightly out-of-date information can lead to unnecessary > > logins and other events that will seriously degrade the > > performance of the storage network. > > I'm not sure I see the need for storage devices to > "re-register" themselves > frequently since storage is not typically a highly dynamic > configuration > environment. You've made some statements about the real-time needs of > storage, but without specific examples I don't see how "real-time > monitoring" is a crucial requirement of a centralized storage resource > management service. See below. > > As for your concerns about SA's re-registering too often and > overwhelming > the DA, this "push" model is viewed as having less problems > than the "poll" > model where a centralized application requests status updates > from multiple > devices (but there are tradeoffs with both models). This is a classic > networked device monitoring problem, I don't think the group > that developed > SLP would have ignored it in their protocol service design. > > > 4) State Change Notifications. This is important to > > support failover and redundancy capabilities, and to > > ensure that initiators can persistently maintain their > > sessions with targets in the event of network topology > > changes. > > This area of service really applies much more to a Fibre > Channel domain than > an IP/iSCSI domain, due to differences in protocols. > Initiators shouldn't > need notification of target devices "going away", since the > TCP connection > provides that information. As for devices being added, there TCP can take minutes to time out. The polling iSNS does gives iSCSI another tool to detect when a device or port has been disconnected. Sure, as David pointed out it's not failsafe, since the iSNS client could still be running fine despite a failed storage controller. But it's another tool to detect a failed or disconnected device. Otherwise, the alternative is to wait for TCP to time out (several minutes). The iSCSI initiator may decide to initiate another SLP query to see if that device is somewhere on the network. If the database is not real-time and up-to-date, this could lead to further delays before the final action to either abort the session or move it to different TCP connections using alternate target interfaces. This is not a major point, but I always thought having real-time data is better than stale data. I hope you agree. > are a number > of ways to model this, that's another thread of discussion. On first > thought, a model where an administrator triggers the update > of initiators > when a target is added, rather than some automatic or polled > environment > seems more desirable to me. How many OS's can deal with > storage suddenly > "appearing" after initial boot? It seems that SLP could be used by an > application to provide this service if it's deemed necessary, > it remains to > be specified "how". > > > Furthermore, it would be helpful if you clarify whether your > > statements are representing the iSCSI NDT or only of your > > personal views. I do not believe your statements regarding > > the SLP approach for iSCSI are consistent with what was > > agreed to in the NDT. I believe the consensus was that both > > iSNS and SLP are to be considered for discovery. > > > > > Future - Pursue SLP as the "standard discovery", allowing for > > > other solutions such as iSNS as appropriate. > > > > As an NDT member, I cannot support a decision on making any > > protocol the "standard" without fully addressing the above > > technical issues. The devil is in the details, and only after > > exploring such issues will we be able to avoid future pitfalls > > that may threaten the timely adoption of iSCSI. > > I can't speak for Mark, but I think his intent may have been > to express that > it remains to be fully specified "how" SLP can provide the > same information > as "SendTargets" (we discussed this in the N&D team mtg). > Perhaps he didn't > mean to imply that it would be the only way to discover storage. > > I would speculate that the group/IPS community as a whole has > been focused > on minimal protocol connectivity, and mostly not had > time/bandwidth to weigh > in on the greater "storage directory server" requirements. > Nishan has done > some good work on the iSNS application, the rest of us need Thanks! Josh > to catch up on > considering which of it's features are "requirements of a > generic storage > directory server" and which are value-add. > > Marjorie Krueger > Hewlett-Packard > From owner-ips@ece.cmu.edu Tue Jun 12 23:11:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00671 for ; Tue, 12 Jun 2001 23:11:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5D1JbH05605 for ips-outgoing; Tue, 12 Jun 2001 21:19:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5D1Jag05601 for ; Tue, 12 Jun 2001 21:19:36 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id VAA11702 for ips@ece.cmu.edu; Tue, 12 Jun 2001 21:19:30 -0400 (EDT) Received: from compuserve.com (dal-tgn-tlw-vty17.as.wcom.net [216.192.237.17]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id VAA11695; Tue, 12 Jun 2001 21:19:20 -0400 (EDT) Message-ID: <3B26C06F.2B1FBA8A@compuserve.com> Date: Tue, 12 Jun 2001 20:22:56 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Ips (E-mail)" CC: Charles Monia Subject: Re: Common Encapsulation: Stale Frame Detection in an IP fabric References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Charles, Sorry to take so long responding, only now am I catching up on the complex issues. First, I would have to answer "yes" to the following question from David Black: "Is there any interest in just synchronizing the timestamps between the two ends of an FCIP link without requiring interaction with an external time source?" Such a capability would be very useful to FCIP implementations where the IP Network lacks an SNTP server. David raises the further question: "A possible downside is that an implementation that can support multiple FCIP links may need to maintain a separate time offset (from its internal time source) for each FCIP link." I see this "downside" as a fact of life requirement since the FCIP device has no way of knowing if the time offset is identical for two links. At a minimum the FCIP device would have to interrogate each link to verify its time offset. Having gone to that much trouble, I see no reason why the discovered values would not be maintained separately. >From my perspective, the downside issues for David's proposal are as follows: 1) The common encapsulation draft will need to recognize the two mechanisms for handling time. Since a common flag bit has already been proposed for "time valid" the simplest method for recognizing both time mechanisms would be to have one "valid flag" bit for each. 2) It seems likely that an efficient implementation of David's proposal would not use the SNTP time format. This possibility would have to be dealt with in the common encapsulation draft. 3) The mechanism non-SNTP-server mechanism for determining the offset time would have to be specified somewhere. Past implementations have used FC frames for this purpose, and that suggests that the mechanism would not be specified in the common encapsulation draft. However, I can imagine trying to shoe-horn such a capability in to common encapsulation header. I think it is a bad idea since a possible result is common encapsulation headers that do not encapsulate FC frames. But maybe I have missed something here. Despite these downside issue, I still think a one-link end-to-end time stamp is a good idea. Anybody else agree? Turning to Charles' 23 May proposal I think it is generally complete and could be added to the common encapsulation draft without too much trouble. My concerns are as follows: 11) I am not certain exactly what parts of the proposal are intended to go in the common encapsulation draft or where they are intended to go. 12) I do not understand the purpose of the text near the end of the proposal, beginning with "Setting the enforcement time limit." It seems to me that the encapsulation element should be told exactly one upper limit value for the IP Network transit time of an encapsulated frame. This time limit should be provided by the 'Fibre Channel' component of which the encapsulation element is a part. For example, an FC Switch would set a time limit based on its determination of how R_A_TOV is to be divided for a given FC Fabric routing. I believe the discussion of E_D_TOV and R_A_TOV should not be included in the common encapsulation draft. 13) I believe that the following needs to be reworded: "d) If the incoming frame has a non-zero time stamp, the receiving node shall compute the time in flight and compare it against the limit specified for the IP fabric." I think it would be better to drop the "IP fabric" since that term is specific to only one of the users of the common encapsulation. I also would prefer not to have "receiving node" in the wording because that concept has no definition in the common encapsulation draft. I would suggest: "d) If an encapsulation header contains a non zero value in the Time Stamp [integer] field, the time in flight SHALL be computed by subtracting the reference time from the Time Stamp [integer] and Time Stamp [fraction] fields." Quite probably similar wording changes are needed elsewhere in the proposal. Thanks. Ralph... On 23 May 2001 Charles Monia wrote: > > Hi: > > This note is a strawman proposal for detecting stale FC frames using the > features present in the common encapsulation specification. > > The spec includes provisions for time tagging a frame in order to detect > frames that have exceeded the lifetime guarantees expected of a Fibre > Channel fabric (R_A_TOV). > > A fibre channel fabric must guarantee that the maximum time in flight for > any frame will not exceed the limit specified by the R_A_TOV parameter. In > FC fabrics, R_A_TOV is defined by the fabric and supplied to the N_PORT in > the fabric login 'accept' response. The default value is 10 seconds. > Failure to meet this guarantee may result in stale frames associated with > defunct transactions. These frames, if received outside the R_A_TOV window, > could cause failures and data corruption. > > In a closed FC fabric, the R_A_TOV limit is guaranteed by switch element > design and control of the fabric topology. There is no enforcement > mechanism. In contrast, such control may not be possible in an IP fabric. > In most cases, the IP network will, almost certainly, consist of > heterogeneous components and the user cannot be assumed to have full control > over the infrastructure and its topology. For that reason some explicit way > to enforce the flight time guarantee must be provided. The FC frame > encapsulation format provides the means for this enforcement at the edges of > the IP network by allocating space for a time stamp which is applied when > the frame is injected into the IP network and may be checked by the > receiving node. > > The following is a proposal for managing time base synchronization at the > TCP end nodes. > > The protocol for synchronizing an end node time base is SNTP. In order to > insure that all nodes are time-aligned, they should obtain the address of a > reference SNTP server via a hard-wired address or by querying an appropriate > repository via SLP or some other protocol. If multiple SNTP server > addresses are provided, the servers must be synchronized. Alternatively, a > multicast group address may be used in support of operation in Anycast mode. > Implementation of Anycast mode is as specified in RFC 2030, including the > precautions defined in that document. Multicast mode should not be used. > > An SNTP server may use any one of the time reference sources listed in RFC > 2030. The resolution of the time reference MUST be 125 milliseconds or > better. > > If support for stale frame detection by a node is optional, a node that > does not enforce the flight time limit shall set the time stamp field in the > encapsulation header of an outgoing frame to 0,0 and shall ignore the > contents of the timestamp for incoming frames. A node that supports stale > frame detection shall implement the time stamp with a precision of 0.125 > seconds or better. > > With regard to the time base, the node is in either the synchronized or > unsychronized state. When in the unsynhronized state, the node shall > > a) Set the time stamp field to 0,0 for all outgoing frames > b) Ignore the time stamp field for all incoming frames. > > When in the synchronized state, the node shall: > > a) Set the time stamp field for each outgoing frame in accordance with the > node's internal time base > b) Check the time stamp field of each incoming frame. > c) If the incoming frame has a time stamp of 0,0, the receiving node shall > not test the frame to determine if it is stale. > d) If the incoming frame has a non-zero time stamp, the receiving node > shall compute the time in flight and compare it against the limit specified > for the IP fabric. > e) If the result in step (d) exceeds the enforcement time limit, the frame > shall be discarded. Otherwise, the frame shall be accepted. > > A node enters the synchronized state upon receiving a successful response to > an SNTP query. > > A node shall enter the unsynchronized state: > > a) Upon power up and before the succesful completion of an SNTP query > b) When an unsuccesful SNTP query occurs. > > Setting the enforcement time limit. > > In general, > > 2* E_D_TOV < Stale Frame time limit < R_A_TOV > > Where E_D_TOV is the FC time limit between expected events such as the > arrival of two successive frames in a sequence. > > A rule of thumb for the stale frame time limit is .5 * R_A_TOV. > > Charles > > Charles Monia > Senior Technology Consultant > Nishan Systems > email: cmonia@nishansystems.com > voice: (408) 519-3986 > fax: (408) 435-8385 From owner-ips@ece.cmu.edu Tue Jun 12 23:11:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00682 for ; Tue, 12 Jun 2001 23:11:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5D1J1u05548 for ips-outgoing; Tue, 12 Jun 2001 21:19:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5D1J0g05544 for ; Tue, 12 Jun 2001 21:19:00 -0400 (EDT) Received: (cpmta 19781 invoked from network); 12 Jun 2001 18:18:53 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.214) with SMTP; 12 Jun 2001 18:18:53 -0700 X-Sent: 13 Jun 2001 01:18:53 GMT From: "Douglas Otis" To: "Charles Monia" , "Ips Reflector \(E-mail\)" Subject: RE: iSCSI: Wrapping up SendTargets Date: Tue, 12 Jun 2001 18:16:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Charles, Without drawing any conclusions as to the general merits of iSNS, it is new, based on a simple flat file, and likely not the best choice when implementing a difficult to maintain boot ROM code. There are alternative solutions to the indicated problems that have driven a perceived need for a new service in my view. From that perspective, it would be much better to use something already mature and stable. I agree that a convergence on a common solution would be good, but my hopes would be to use something already in place based on mature and stable code. Doug > My .02: > > We either have a common tool for discovery and SAN management or we have > (perhaps) a common discovery tool plus an assortment of ad-hoc > 'value-added' > solutions to fill the gaps. In my opinion, such an outcome would make it > impossible to integrate heterogeneous storage products into the enterprise > environment. > > With that concern in mind, the iSNS authors decided that a single SAN > management and discovery protocol was essential. As with iSCSI, > we believed > the right place to start was with a model that was widely deployed and > supported by existing storage management products. > > As to alternate approaches, I believe it will always be possible > to point to > this or that tool or protocol that does or can be extended to do > some piece > of iSNS functionality. What's been missing, however, is a comprehensive, > well-articulated model into which all of these fit and a willingness to > deploy the implementations so we can all do a test drive. > > If anyone has an alternative model and implementation, I would encourage > them to put both forward for consideration. > > Charles > > > -----Original Message----- > > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > > [mailto:marjorie_krueger@hp.com] > > Sent: Monday, June 11, 2001 4:41 PM > > To: Ips Reflector (E-mail) > > Subject: RE: iSCSI: Wrapping up SendTargets > > > > > > Josh, > > > > > Before you or anyone calls consensus, I would like to see > > > how SLP can solve the following issues: > > > > > > 1) Management of Discovery Domains. You don't want > > > incompatible file systems discovering each other, or > > > very bad things will happen. Say 'goodbye' to the Unix > > > file system who's host is discovered by SLP.... > > > > This function is the domain of an application value-add, and > > does not need > > to be specified in the SLP protocol. It is perfectly feasible for an > > application that provides storage discovery services using > > SLP to filter the > > information given to a particular initiator based on that initiator's > > identity (just as a target would when responding to SendTargets). The > > 'management of discovery domains' is a 'storage network > > management' related > > value-add feature of an application, not something SLP must specify. > > > > > 2) Transfer of X.509 digital certificates. SLP cannot > > > easily transfer binary entities. This affects the iSCSI > > > target device's ability to enforce its access control list. > > > > Again, this may be an application value-add, it's not a > > requirement for > > storage discovery. Security infrastructure is painful to > > administer. Seems > > to me as if a user would chose a generic security solution > > using something > > like SCEP protocol, which would work for a variety of > > applications, not just > > storage. > > > > > 3) Monitoring of available devices. SLP relies upon > > > service agents re-registering periodically, in order to keep > > > the freshness of its database entries. But this leads to a > > > dilemma: if SA's re-register too often, the DA will be > > > overwhelmed. And if they register not often enough, then > > > you will have stale device entries. The fact is, SLP was > > > not designed to be a real-time discovery protocol. But in > > > storage networks, real-time information is crucial, as even > > > slightly out-of-date information can lead to unnecessary > > > logins and other events that will seriously degrade the > > > performance of the storage network. > > > > I'm not sure I see the need for storage devices to > > "re-register" themselves > > frequently since storage is not typically a highly dynamic > > configuration > > environment. You've made some statements about the real-time needs of > > storage, but without specific examples I don't see how "real-time > > monitoring" is a crucial requirement of a centralized storage resource > > management service. > > > > As for your concerns about SA's re-registering too often and > > overwhelming > > the DA, this "push" model is viewed as having less problems > > than the "poll" > > model where a centralized application requests status updates > > from multiple > > devices (but there are tradeoffs with both models). This is a classic > > networked device monitoring problem, I don't think the group > > that developed > > SLP would have ignored it in their protocol service design. > > > > > 4) State Change Notifications. This is important to > > > support failover and redundancy capabilities, and to > > > ensure that initiators can persistently maintain their > > > sessions with targets in the event of network topology > > > changes. > > > > This area of service really applies much more to a Fibre > > Channel domain than > > an IP/iSCSI domain, due to differences in protocols. > > Initiators shouldn't > > need notification of target devices "going away", since the > > TCP connection > > provides that information. As for devices being added, there > > are a number > > of ways to model this, that's another thread of discussion. On first > > thought, a model where an administrator triggers the update > > of initiators > > when a target is added, rather than some automatic or polled > > environment > > seems more desirable to me. How many OS's can deal with > > storage suddenly > > "appearing" after initial boot? It seems that SLP could be used by an > > application to provide this service if it's deemed necessary, > > it remains to > > be specified "how". > > > > > Furthermore, it would be helpful if you clarify whether your > > > statements are representing the iSCSI NDT or only of your > > > personal views. I do not believe your statements regarding > > > the SLP approach for iSCSI are consistent with what was > > > agreed to in the NDT. I believe the consensus was that both > > > iSNS and SLP are to be considered for discovery. > > > > > > > Future - Pursue SLP as the "standard discovery", allowing for > > > > other solutions such as iSNS as appropriate. > > > > > > As an NDT member, I cannot support a decision on making any > > > protocol the "standard" without fully addressing the above > > > technical issues. The devil is in the details, and only after > > > exploring such issues will we be able to avoid future pitfalls > > > that may threaten the timely adoption of iSCSI. > > > > I can't speak for Mark, but I think his intent may have been > > to express that > > it remains to be fully specified "how" SLP can provide the > > same information > > as "SendTargets" (we discussed this in the N&D team mtg). > > Perhaps he didn't > > mean to imply that it would be the only way to discover storage. > > > > I would speculate that the group/IPS community as a whole has > > been focused > > on minimal protocol connectivity, and mostly not had > > time/bandwidth to weigh > > in on the greater "storage directory server" requirements. > > Nishan has done > > some good work on the iSNS application, the rest of us need > > to catch up on > > considering which of it's features are "requirements of a > > generic storage > > directory server" and which are value-add. > > > > Marjorie Krueger > > Hewlett-Packard > > > From owner-ips@ece.cmu.edu Tue Jun 12 23:11:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00693 for ; Tue, 12 Jun 2001 23:11:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5D1JPF05592 for ips-outgoing; Tue, 12 Jun 2001 21:19:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5D1JNg05587 for ; Tue, 12 Jun 2001 21:19:24 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 18:19:18 -0700 Message-ID: From: Charles Monia To: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Tue, 12 Jun 2001 18:19:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Jim: Thanks for bringing this back on point. > The choices are, it seems, that *every* box would need to > support at least > one of: > a) SendTargets > b) modified SLP > c) iSNS > As I recall, the issue was whether or not to require support for SendTargets. I thought the consensus on that issue was 'yes', irrespective of the other two issues. So, in my opinion, the matter of SendTargets was indeed 'wrapped up' as far as this thread is concerned. That said, of course, the others remain open. Charles > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Tuesday, June 12, 2001 4:56 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: Wrapping up SendTargets > > > > Folks, > > I think this thread is wandering off the field. > > The question is the issue of SendTargets. Let's remind > ourselves of the > original purpose of this proposed protocol: namely, it's > designed for a > storage box that contains one or more iSCSI target devices to > report about > ITSELF, about what's in it! This includes both a list of the > iSCSI targets > it has PLUS the session coordination (via tags) of the various > IPaddress/tcpport combos it supports. > > In other words, it's job is to report about itself! The use > of (unicast) > SLP as an alternative to SendTargets was focused exactly on the same > question: I ask a single box to tell me about itself. This > function lies > between the two extremes of (a) static configuration of > initiators and (b) > centralized management via iSNS style services. > > Somehow, someway, we need to define a protocol for a box to > "tell us about > itself" in the absense of the centralized management > infrastructure. That > seems critical to me. Even if I want to do static > configuration, the guy > doing the configuration needs a way to get at the guts of each new box > he/she rolls into the environment. > > The choices are, it seems, that *every* box would need to > support at least > one of: > a) SendTargets > b) modified SLP > c) iSNS > > What's the consensus on the protocol we aim for to solve this > middle ground > discovery problem? > Jim Hafner > From owner-ips@ece.cmu.edu Tue Jun 12 23:54:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01421 for ; Tue, 12 Jun 2001 23:54:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5D2VnI10326 for ips-outgoing; Tue, 12 Jun 2001 22:31:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5CHK5g00691 for ; Tue, 12 Jun 2001 13:20:05 -0400 (EDT) Received: from eddylaptop (h00e098880aa4.ne.mediaone.net [66.31.75.244]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f5CHK2603659; Tue, 12 Jun 2001 13:20:02 -0400 (EDT) From: "Eddy Quicksall" To: , Subject: iSCSI: All text keys MUST be supported? Date: Tue, 12 Jun 2001 13:20:01 -0400 Message-ID: <007201c0f363$eb9a8c60$b101a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section "2.8.3 Text" says: All of these keys, except for the X- extension format, MUST be supported by iSCSI initiators and targets. But it further says: Any other key not understood by the target may be ignored without affecting basic function. If the Text Response does not contain a key that was requested, the initiator must assume that the key was not understood by the target or, whenever appropriate, that the response was "none". These two statements seem contradictory (I don't think the 2nd is talking about only the X keys). I vote for removing the 1st paragraph above and going with the 2nd. That way we would not have to insist that every key be supported ... the requester would just take the default if the receiver did not support the key. Actually, section "2.9.3 Text Response Data" says: If the Text Response does not contain a key that was requested, the initiator must assume that the key was not understood by the target or that the answer is =none. This seems to backup the 2nd paragraph above. Eddy@Quicksall.com From owner-ips@ece.cmu.edu Wed Jun 13 01:35:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03824 for ; Wed, 13 Jun 2001 01:35:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5D3njO15046 for ips-outgoing; Tue, 12 Jun 2001 23:49:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5D3nhg15042 for ; Tue, 12 Jun 2001 23:49:43 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 152C718F6 for ; Tue, 12 Jun 2001 23:49:43 -0400 (EDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id UAA22861 for ips@ece.cmu.edu; Tue, 12 Jun 2001 20:50:52 -0700 (PDT) Message-Id: <200106130350.UAA22861@core.rose.hp.com> Subject: RE: iSCSI: Wrapping up SendTargets To: ips@ece.cmu.edu Date: Tue, 12 Jun 2001 20:50:52 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > >iSCSI Team, >I think that Jim has said it well. I had a proposal about an Annex, for >the SendTargets, but whether we do that or not, I am getting the feeling >that most folks think, at least for this version of the protocol that we >keep SendTargets, and the subset that can be used as a Report Portal >Groups. Even Mark, even though he thought he could Hack the SLP Source >code to do a similar thing, thought that it was best to keep SendTargets. > >I would like to propose that we Close on Keeping the SendTargets command, >and the subset that is either Report Portal Groups or SendTargets Target Name> (which returns only the information for that target only). > >Now as to where we put the command. I suggested an Annex, but can clearly >live with it in the Main document. I seemed to get very little support for >the idea of the Annex, and since I think that the functions of Report >Portal Groups, must be part of the base, I would like to suggest that we >either >1) Place the SendTargets in the Annex, and put a Report Portal Groups in >the main document, or >2) Keep the Send Targets in the Main Document and add the argument of > > >Please state your positions My support is for option 2 for the reasons that I alrady listed in my previous posting. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com > >. >. >. >John L. Hufferd >Senior Technical Staff Member (STSM) >IBM/SSG San Jose Ca >(408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 >Internet address: hufferd@us.ibm.com > > >Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 06/12/2001 04:56:10 PM > >Sent by: owner-ips@ece.cmu.edu > > >To: ips@ece.cmu.edu >cc: >Subject: RE: iSCSI: Wrapping up SendTargets > > > > >Folks, > >I think this thread is wandering off the field. > >The question is the issue of SendTargets. Let's remind ourselves of the >original purpose of this proposed protocol: namely, it's designed for a >storage box that contains one or more iSCSI target devices to report about >ITSELF, about what's in it! This includes both a list of the iSCSI targets >it has PLUS the session coordination (via tags) of the various >IPaddress/tcpport combos it supports. > >In other words, it's job is to report about itself! The use of (unicast) >SLP as an alternative to SendTargets was focused exactly on the same >question: I ask a single box to tell me about itself. This function lies >between the two extremes of (a) static configuration of initiators and (b) >centralized management via iSNS style services. > >Somehow, someway, we need to define a protocol for a box to "tell us about >itself" in the absense of the centralized management infrastructure. That >seems critical to me. Even if I want to do static configuration, the guy >doing the configuration needs a way to get at the guts of each new box >he/she rolls into the environment. > >The choices are, it seems, that *every* box would need to support at least >one of: >a) SendTargets >b) modified SLP >c) iSNS > >What's the consensus on the protocol we aim for to solve this middle ground >discovery problem? >Jim Hafner > > > > > From owner-ips@ece.cmu.edu Wed Jun 13 01:41:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04022 for ; Wed, 13 Jun 2001 01:41:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5D4KeG16897 for ips-outgoing; Wed, 13 Jun 2001 00:20:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5D4Kcg16891 for ; Wed, 13 Jun 2001 00:20:38 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id 33A4F1196 for ; Tue, 12 Jun 2001 21:20:37 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id VAA29197 for ips@ece.cmu.edu; Tue, 12 Jun 2001 21:21:46 -0700 (PDT) Message-Id: <200106130421.VAA29197@core.rose.hp.com> Subject: RE: iSCSI: statement on mandatory/optional To: ips@ece.cmu.edu Date: Tue, 12 Jun 2001 21:21:46 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I admit that I could be off on what's the right IETF language. In general, you suggest that the level of requirement specification should be at least at the section level - than at the beginning of the document. I am okay with that. >What Mallikarjun proposes above uses negotiation as an >announcement mechanism (one side uses negotiation only >to tell the other side "I'm doing "). That's definitely >an acceptable possibility, but may not be appropriate in >all cases. I am not sure what exactly is meant here. Negotiation is a process of announcing capabilities, and settling on what's acceptable to both.... Would the following wording express what I wanted better, say for digests? Receivers are REQUIRED to support digests and senders MAY use digests. than the current "and MUST be implemented by every iSCSI initiator and target." in rev06. I agree with your suggestion to use REQUIRED for "not implemented" and the negotiation itself where appropriate - this also implies to me that the "base" functionality support is not necessarily REQUIRED when an implementation supports a feature defined as OPTIONAL. If this is true, I suggest to Julian that language be added for synch and steering to make the no sync-and-steering mode REQUIRED, in addition to stating that synch and steering is OPTIONAL. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >While I agree with the intent of the proposed explanatory >text, I don't thing the wording is a good idea. To start >with, the appropriate words to express levels of requirements >are MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, and their >synonyms as defined in RFC 2119. The usual practice is >to have the RFC-2119 words that express the level of >requirement be located near the description of the >feature and/or behavior that is required - this simplifies >things for the reader. A summary at the end of a >section or subsection may be a useful way to structure >things to ensure that nothing's been missed. > >As a result, the following text is not needed: > >> - All the features that are specified in this draft are >> mandatory to implement and mandatory to use, unless otherwise >> stated. > >The rest of the proposed text appears to be about >negotiation (implicit or explicit). > >> - Features that are identified as "mandatory to implement >> but optional to use" (like the digests) MUST be implemented >> and MUST be honored by one side when the other side uses >> them (as in a PDU type), or wants to use them (as in negotiation). > >The right thing to do here is for each such feature, >spell out exactly what the REQUIRED (MUST) or RECOMMENDED >(SHOULD) behavior is. The PDU type is easy - one side >just sends it and since support for it is REQUIRED, the >other side has to do what the specification REQUIRES. >For negotiation, the behavior would need to be spelled >out in the appropriate place (probably with the feature >description, and possibly also with the text tag description). >What Mallikarjun proposes above uses negotiation as an >announcement mechanism (one side uses negotiation only >to tell the other side "I'm doing "). That's definitely >an acceptable possibility, but may not be appropriate in >all cases. > >> - Features that are identified as "optional to implement" >> (like the synch and steering layer) imply that implementations >> that support the features MUST interoperate with other >> implementations that do not support these features (i.e. >> implementations are guaranteed to be interoperable regardless >> of the feature support). > >Again this principle is generally implicit in the IETF dictum >of "be conservative in what you send, liberal in what you >accept". For features where this matters (there's risk of >a receiver being confused by a sender making a different >implementation choice), one possibility is to make support >OPTIONAL for the sender and REQUIRED by the receiver (which is >the previous case), another is to make it negotiable and >REQUIRE support for "not implemented" as well as the behavior >behavior to negotiate it. > >Thanks, >--David > >--------------------------------------------------- >David L. Black, Senior Technologist >EMC Corporation, 42 South St., Hopkinton, MA 01748 >+1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 >black_david@emc.com Mobile: +1 (978) 394-7754 >--------------------------------------------------- > > >> -----Original Message----- >> From: Mallikarjun C. [mailto:cbm@rose.hp.com] >> Sent: Thursday, June 07, 2001 1:44 PM >> To: ips@ece.cmu.edu >> Subject: iSCSI: statement on mandatory/optional >> >> Julian, >> >> I suggest the following explanatory text to be added to >> the iSCSI main draft (possibly as section 1.2.1). I really >> think this (in an abstract sense) helps readers to understand >> the optionality or otherwise of iSCSI features. >> >> Mandatory and optional features >> >> - All the features that are specified in this draft are >> mandatory to implement and mandatory to use, unless otherwise >> stated. >> - Features that are identified as "mandatory to implement >> but optional to use" (like the digests) MUST be implemented >> and MUST be honored by one side when the other side uses >> them (as in a PDU type), or wants to use them (as in negotiation). >> - Features that are identified as "optional to implement" >> (like the synch and steering layer) imply that implementations >> that support the features MUST interoperate with other >> implementations that do not support these features (i.e. >> implementations are guaranteed to be interoperable regardless >> of the feature support). >> >> Regards. >> -- >> Mallikarjun >> >> >> Mallikarjun Chadalapaka >> Networked Storage Architecture >> Network Storage Solutions Organization >> MS 5668 Hewlett-Packard, Roseville. >> cbm@rose.hp.com >> > From owner-ips@ece.cmu.edu Wed Jun 13 03:41:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17149 for ; Wed, 13 Jun 2001 03:41:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5D5edd21914 for ips-outgoing; Wed, 13 Jun 2001 01:40:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5D5ecg21910 for ; Wed, 13 Jun 2001 01:40:38 -0400 (EDT) Received: (cpmta 210 invoked from network); 12 Jun 2001 22:40:32 -0700 Received: from dsl-64-130-130-105.telocity.com (HELO littlejoy) (64.130.130.105) by smtp.telocity.com (209.228.33.217) with SMTP; 12 Jun 2001 22:40:32 -0700 X-Sent: 13 Jun 2001 05:40:32 GMT From: "Douglas Otis" To: "Charles Monia" , Subject: RE: iSCSI: Wrapping up SendTargets Date: Tue, 12 Jun 2001 22:38:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Charles, You seem to leave out existing stable management servers that already exist and do not need modification such as LDAP, etc. If you need to have signaling perhaps just servers would need to support something as complex as a Directory User Agent. Any SAN agent detecting or creating a critical change would send an ICMP Code (41?) "SAN_Notice" to those SAN servers logged as 'running' where these running servers (targets) acknowledge ICMP Code (42?) "SAN_Rely". All IP stacks support ICMP. This signaling could be invoked when a server detects an error and investigates running status from the management server or at predetermined intervals. This would be a smaller change than writing a new server or modifying SLP to do signaling. It would seem to apply to a broad range of SAN related systems. Doug > Hi Jim: > > Thanks for bringing this back on point. > > > The choices are, it seems, that *every* box would need to > > support at least > > one of: > > a) SendTargets > > b) modified SLP > > c) iSNS > > > > As I recall, the issue was whether or not to require support for > SendTargets. I thought the consensus on that issue was 'yes', irrespective > of the other two issues. So, in my opinion, the matter of SendTargets was > indeed 'wrapped up' as far as this thread is concerned. > > That said, of course, the others remain open. > > Charles > > -----Original Message----- > > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > > Sent: Tuesday, June 12, 2001 4:56 PM > > To: ips@ece.cmu.edu > > Subject: RE: iSCSI: Wrapping up SendTargets > > > > > > > > Folks, > > > > I think this thread is wandering off the field. > > > > The question is the issue of SendTargets. Let's remind > > ourselves of the > > original purpose of this proposed protocol: namely, it's > > designed for a > > storage box that contains one or more iSCSI target devices to > > report about > > ITSELF, about what's in it! This includes both a list of the > > iSCSI targets > > it has PLUS the session coordination (via tags) of the various > > IPaddress/tcpport combos it supports. > > > > In other words, it's job is to report about itself! The use > > of (unicast) > > SLP as an alternative to SendTargets was focused exactly on the same > > question: I ask a single box to tell me about itself. This > > function lies > > between the two extremes of (a) static configuration of > > initiators and (b) > > centralized management via iSNS style services. > > > > Somehow, someway, we need to define a protocol for a box to > > "tell us about > > itself" in the absense of the centralized management > > infrastructure. That > > seems critical to me. Even if I want to do static > > configuration, the guy > > doing the configuration needs a way to get at the guts of each new box > > he/she rolls into the environment. > > > > The choices are, it seems, that *every* box would need to > > support at least > > one of: > > a) SendTargets > > b) modified SLP > > c) iSNS > > > > What's the consensus on the protocol we aim for to solve this > > middle ground > > discovery problem? > > Jim Hafner > > > From owner-ips@ece.cmu.edu Wed Jun 13 11:48:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25600 for ; Wed, 13 Jun 2001 11:48:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DDOtO29298 for ips-outgoing; Wed, 13 Jun 2001 09:24:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gda-server ([202.88.153.15]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DDOpg29293 for ; Wed, 13 Jun 2001 09:24:52 -0400 (EDT) Received: from [192.168.0.132] by gda-server (ArGoSoft Mail Server, Version 1.5 (1.5.0.8)); Wed, 13 Jun 2001 18:48:31 MIME-Version: 1.0 Message-Id: <3B2768F9.000006.12787@gda_tr3> Date: Wed, 13 Jun 2001 18:52:01 +0530 (India Standard Time) Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_PGEV12S0000000000000" X-Mailer: IncrediMail 2001 (1400185) From: "Sathya" X-Priority: 3 X-FID: FLAVOR00-NONE-0000-0000-000000000000 To: Cc: "sathya" Subject: iFCP implementation doubts Sender: owner-ips@ece.cmu.edu Precedence: bulk --------------Boundary-00=_PGEV12S0000000000000 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_PGEVBHK0000000000000" --------------Boundary-00=_PGEVBHK0000000000000 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I am working on iFCP/FCIP implementation for bringing up a LAN -SAN Swit= ch. I have some doubts on the iFCP protocol implementation The iFCp document specifies a Switch topology for connecting the iFCP gat= eway , the master Switch and the FC elements. Is this topology a mandator= y or can we go with a FC-AL configuration ? If Switch Topology: 1. what shall be the interaction between the iFCP gateway and the Pricipa= l switch in terms of FC Domian address and N port ID assignments?=20 2. Is it possible for a iFCP GW and the FC Switch (Master) to have transa= ctions other than via the E-port 3. Or the iFCP GW can take the functionality of even the Principal switch= ? 4. For an existing iFCP network will it be possible to add the iFCP gatew= ay If so what will be the methods to handle the already assigned address= es without any conflict.? If FC-AL Topology: ----- (if it is allowed by the iFCP ) 1. Can we have the iFCP GW as the Loop Master in the FC-AL and the FC Swi= tch as one of the loop element? 2. If (1) is allowed then whether the Domain ID assignment for the FC Swi= tch is controlled by the iFCP GW or the the Switch can have its own domai= n ( i.e ) the switch can be independent on maintaining its FC domain by h= aving a separate iSNS Server as a repository for IDs. Thanx & Regards, N.Sathyanarayana, Member Technical Staff, GDA Technologies Ltd., 18,Bawa Road, Alwarpet, Chennai - 600018 India Tel : 91-44-4993832 Fax : 91-44-4661653 catch me at : n.sathya@gdatech.co.in --------------Boundary-00=_PGEVBHK0000000000000 Content-Type: Text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi all,
 I am working on iFCP/FCIP implementation for bringing up= a LAN=20 -SAN Switch. I have some doubts on the iFCP protocol implementation=
 
 
The iFCp document specifies a Switch topology for connecting t= he iFCP=20 gateway , the master Switch and the FC elements. Is this topology a= =20 mandatory or can we go with a FC-AL configuration ?
 
 
If Switch Topology:
 
1. what shall be the interaction between the iFCP gateway and = the=20 Pricipal switch in terms of FC Domian address and N port ID assignm= ents?=20
 
2. Is it possible for a iFCP GW and the FC Switch (Master) to = have=20 transactions other than via the E-port
 
3. Or the iFCP GW can take the functionality of even the Princ= ipal=20 switch?
 
4. For an existing iFCP network will it be possible to add the= iFCP=20 gateway  If so what will be the methods to handle the already=20 assigned addresses without any conflict.?
 
If FC-AL Topology: ----- (if it = is=20 allowed by the iFCP )
 
1. Can we have the iFCP GW as the Loop Master in the FC-AL and= the FC=20 Switch as one of the loop element?
 
2. If (1) is allowed then whether the Domain ID assignment for= the FC=20 Switch is controlled by the iFCP GW or the the Switch can have its = own=20 domain ( i.e ) the switch can be independent on maintaining its FC = domain=20 by having a separate iSNS Server as a repository for IDs.=
 
 
Thanx &=20 Regards,
N.Sathyanarayana,
Member Technical Staff,
GDA=20 Technologies Ltd.,
18,Bawa Road,
Alwarpet,
Chennai -=20 600018
India
Tel  :=20 91-44-4993832
Fax :=20 91-44-4661653
catch me at : n.sathya@gdatech.co.in
=09 =09 =09 =09 =09 =09 =09
_________________________________________________
IncrediMail - Email has finally= =20 evolved - Click=20 Here --------------Boundary-00=_PGEVBHK0000000000000-- --------------Boundary-00=_PGEV12S0000000000000 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 R0lGODlheQBAAPABAAAAAL29vSH5BAEAAAEALAAAAAB5AEAAAAL+jI+py+0Po5y02ouz3rz7D4bi SJbmiabq+gGuy8YmfADyHdoIjfeavvMJMcChkXhMXorK5oPpjCqgUiFvWlVeE1Tp67vaBrO1hXhk 6wbUSTW7tW68jew5R9e1Wx1UvQTP4NcjaAB0RmFoRrZGWESIVai4yKjnuGHJNVnz8jSWgempucn1 xfmYGRonShqYasF0ddrW51oBBepUmicZ+cMrmwJ7W0gTywN42IuqGnULq8y4k9ZrujsF6MVLHW0c ifdNazbtFc5cyhxNCUYM7Yae69xdnJymG8sHrMK5mQ/Nhz/pXLIJlVYhumNQRL93Ce8I2jewIRJE +yQqtDgL45ElhRo9VOwIMqTIkSRLmjyJMqXKlSxbunwJM6bMmTRr2ryJM2fLAgA7 --------------Boundary-00=_PGEV12S0000000000000-- From owner-ips@ece.cmu.edu Wed Jun 13 14:58:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29321 for ; Wed, 13 Jun 2001 14:58:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DHY2t18200 for ips-outgoing; Wed, 13 Jun 2001 13:34:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DHY0g18195 for ; Wed, 13 Jun 2001 13:34:00 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA19043; Wed, 13 Jun 2001 10:33:55 -0700 (PDT) Received: from aimexc06.corp.adaptec.com (aimexc06.corp.adaptec.com [162.62.62.46]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA09522; Wed, 13 Jun 2001 10:23:19 -0700 (PDT) Received: by aimexc06.corp.adaptec.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 10:33:54 -0700 Message-ID: From: "Sperry, Todd" To: "'John Hufferd'" , ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Wed, 13 Jun 2001 10:33:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk John & Company, I think that the arguments for (and against) leaving SendTargets in the main draft, as an annex, or outside of the iSCSI draft altogether all have some merit and that's why this is a difficult decision. I tend to agree with Marjorie's assesment of the situation... >IMO, it's a judgement call where you draw the line between architectural >purity and practical functional encapsulation. My current feeling is that a >limited SendTargets function adds a small amount of implementation burden >and a large amount of functional value to product solutions. The work towards implementing the SendTargets targets functionality outside of iSCSI should likely continue. At this point, we have Mark's verification of workability, but still we have questions about security/authentication, changes to drafts, etc. Finally, the ReportPortalGroups is good idea, and it seems to me more closely tied to the session nature of the iSCSI protocol. However, because I'm leaning towards leaving SendTargets in the main draft, I would recommend the SendTargets syntax. So, I'm arguing for John's suggestion of #2. Thanks, Todd. -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, June 12, 2001 6:09 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets iSCSI Team, I think that Jim has said it well. I had a proposal about an Annex, for the SendTargets, but whether we do that or not, I am getting the feeling that most folks think, at least for this version of the protocol that we keep SendTargets, and the subset that can be used as a Report Portal Groups. Even Mark, even though he thought he could Hack the SLP Source code to do a similar thing, thought that it was best to keep SendTargets. I would like to propose that we Close on Keeping the SendTargets command, and the subset that is either Report Portal Groups or SendTargets (which returns only the information for that target only). Now as to where we put the command. I suggested an Annex, but can clearly live with it in the Main document. I seemed to get very little support for the idea of the Annex, and since I think that the functions of Report Portal Groups, must be part of the base, I would like to suggest that we either 1) Place the SendTargets in the Annex, and put a Report Portal Groups in the main document, or 2) Keep the Send Targets in the Main Document and add the argument of Please state your positions . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 06/12/2001 04:56:10 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI: Wrapping up SendTargets Folks, I think this thread is wandering off the field. The question is the issue of SendTargets. Let's remind ourselves of the original purpose of this proposed protocol: namely, it's designed for a storage box that contains one or more iSCSI target devices to report about ITSELF, about what's in it! This includes both a list of the iSCSI targets it has PLUS the session coordination (via tags) of the various IPaddress/tcpport combos it supports. In other words, it's job is to report about itself! The use of (unicast) SLP as an alternative to SendTargets was focused exactly on the same question: I ask a single box to tell me about itself. This function lies between the two extremes of (a) static configuration of initiators and (b) centralized management via iSNS style services. Somehow, someway, we need to define a protocol for a box to "tell us about itself" in the absense of the centralized management infrastructure. That seems critical to me. Even if I want to do static configuration, the guy doing the configuration needs a way to get at the guts of each new box he/she rolls into the environment. The choices are, it seems, that *every* box would need to support at least one of: a) SendTargets b) modified SLP c) iSNS What's the consensus on the protocol we aim for to solve this middle ground discovery problem? Jim Hafner From owner-ips@ece.cmu.edu Wed Jun 13 14:58:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29333 for ; Wed, 13 Jun 2001 14:58:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DG83111875 for ips-outgoing; Wed, 13 Jun 2001 12:08:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DG81g11867 for ; Wed, 13 Jun 2001 12:08:01 -0400 (EDT) Received: from HQMailWeb.Crossroads.com [63.237.99.250:25] by va2mc.ummailbox.net with SMTP id J0613-1207-67a901; Wed, 13 Jun 2001 16:07:48 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 13 Jun 2001 11:07:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: iSCSI: Response codes in SCSI Response Command Date: Wed, 13 Jun 2001 11:07:42 -0500 Message-ID: Thread-Topic: iSCSI: Response codes in SCSI Response Command Thread-Index: AcD0GO1n7hEOdJUaRdGuGG3GiluP2wAB4a5g From: "Robert Griswold" To: "Elliott, Robert" , "ISCSI" , "Sanjeev Bhagat (TRIPACE/Zoetermeer)" X-OriginalArrivalTime: 13 Jun 2001 16:07:43.0123 (UTC) FILETIME=[FA447630:01C0F422] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f5DG81g11871 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I also don't understand the exact mapping that is trying to be implied here. The paragraph seems to imply that the Status / Response field of this PDU is used to report SCSI status as specified in SAM-2, yet the iSCSI status codes (that can also be in the same field?) seem to overload the status responses of SAM-2, namely CHECK CONDITION and CONDITION MET. I have reread the section, but cannot determine if opcode 0x01 can have the status flagged as "iSCSI-specific" or not, as in the Status / Response field contains an iSCSI Response, versus a SCSI Status. Bob Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: Elliott, Robert [mailto:Robert.Elliott@compaq.com] Sent: Monday, June 11, 2001 12:27 PM To: 'ISCSI'; 'Sanjeev Bhagat (TRIPACE/Zoetermeer)' Subject: RE: iSCSI: Response codes in SCSI Response Command SPI-4, FCP-2, SRP, and SST do agree on these values: 0 - task management function complete 1 - FCP specific 2 - command IU/request fields invalid 3 - FCP specific 4 - task management function not supported 5 - task management function failed 6+ - protocol specific It's too late to try to force any more commonality, as those standards already exist. iSCSI has separate command response and task management response IUs (PDUs), making it a bit different from the other protocols. --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com -----Original Message----- From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] Sent: Monday, June 11, 2001 11:10 AM To: 'Julian Satran'; 'ISCSI'; 'Mark Bakke'; 'Ralph Weber' Subject: iSCSI: Response codes in SCSI Response Command Current definition states 2.4.2 Status/Response The Status field is used to report the SCSI status of the command (as specified in [SAM2]). The Response is used to report a Service Response. The exact mapping of the iSCSI response codes to SAM service response symbols is outside the scope of this document. If a SCSI device error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set) the target MUST wait until it receives the a data PDU with the F bit set before sending the Response PDU. Valid iSCSI Response codes are: 0x01 - Target Failure 0x02 - Delivery Subsystem Failure 0x03 - Unsolicited data rejected 0x04 - SNACK rejected 0x80-0xff - Reserved for Vendor-Unique Responses DONT YOU THINK that these response codes be actually mapped in SAM document and be made as standard to be followed by any protocol. So iSCSI should also report the same responses as defined in SAM document. Regards, Sanjeev At's too late to try to force any more commonality, as those standards Wt's too late to try to force any more commonality, as those standards From owner-ips@ece.cmu.edu Wed Jun 13 15:00:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29368 for ; Wed, 13 Jun 2001 15:00:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DHnGK19367 for ips-outgoing; Wed, 13 Jun 2001 13:49:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DHnFg19363 for ; Wed, 13 Jun 2001 13:49:15 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA59444 for ; Wed, 13 Jun 2001 13:31:08 -0400 Received: from f3n41e (d03nm041h.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5DHnB221106 for ; Wed, 13 Jun 2001 11:49:12 -0600 Importance: Normal Subject: iSCSI:Text field in Asynchronous Message To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Kaladhar Voruganti" Date: Wed, 13 Jun 2001 18:49:09 +0100 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/13/2001 10:49:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Will there ever be a need for a Target to send an asynchronous Text message to the initiators (for potential performance optimizations)? According to the current iSCSI specification, the initiators can send Text messages to the target. Moreover, the initiators can send vendor specific X- key/values to the target. Now, why can't the targets also have the ability to send X-key/value pairs to the initiators via Asynch messages? I would like input from people as to whether this feature will be useful. Thanks, Kaladhar Voruganti From owner-ips@ece.cmu.edu Wed Jun 13 15:02:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29460 for ; Wed, 13 Jun 2001 15:02:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DHWPx18065 for ips-outgoing; Wed, 13 Jun 2001 13:32:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DHUSg17919 for ; Wed, 13 Jun 2001 13:30:28 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id TAA180838 for ; Wed, 13 Jun 2001 19:30:21 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5DHSsF22172 for ; Wed, 13 Jun 2001 19:28:54 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A6A.0060093D ; Wed, 13 Jun 2001 19:28:58 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 13 Jun 2001 20:32:03 +0300 Subject: RE: iSCSI: All text keys MUST be supported? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk 1.2.4 reads now: 1.1.1 Text Mode Negotiation During login and thereafter some session or connection parameters are negotiated through an exchange of textual information. In "list" negotiation, the offering party sends a list of values for a key in its order of preference. The responding party answers with the first value from the list it supports and is allowed to use for the specific initiator. The value "none" MUST always be used to indicate a missing function. However, none is a valid selection only if it is explicitly offered and MAY be selected by omission (i.e., =none MAY be omitted). If a target is not supporting, or not allowed to use with a specific initiator, any of the offered options, it may use the value "reject". The values "none" and "reject" are reserved and must be used only as described here. Any key not understood is answered with "NotUnderstood". The general format of text negotiation is: Offer-> =,,..., Answer-> =|reject|NotUnderstood In "numerical" negotiations, the offering and responding party state a numerical value. The result of the negotiation is key dependent; frequently the lower or the higher of the two values is used. Although the initiator is the requesting party and controls the request-response initiation and termination the target can offer key=value pairs of its own as part of a sequence and not only in response to an identical key=value pair offered by the initiator. And 2.8.3 reads: 1.1.1 Text The initiator sends the target a set of key=value or key=list pairs encoded in UTF-8 Unicode. The key and value are separated by a '=' (0x3D) delimiter. Many key=value pairs can be included in the Text block by separating them with null (0x00) delimiters. A list is a set of values separated by comma (0x2C). Large binary items can be encoded using their hexadecimal representation (e.g., 8190 is 0x1FFE) or decimal representation. The maximum length of an individual value (not its string representation) is 255 bytes. The data length of a text command or response SHOULD be less than 4096 bytes. Key names MUST NOT exceed 64 bytes. Key values MUST NOT exceed 255 characters. Character strings are represented as plain text. Numeric and binary values are represented using either decimal numbers or the hexadecimal 0x'ffff' notation. The result is adjusted to the specific key. The target responds by sending its response back to the initiator. The response text format is similar to the request text format. Some basic key=value pairs are described in Appendix A and D. All of these keys, except for the X- extension format, MUST be supported by iSCSI initiators and targets. Manufacturers may introduce new keys by prefixing them with X- followed by their (reversed) domain name, for example the company owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=0000000000000003 Any other key not understood by the target may be ignored by the target without affecting basic function. However the Text Response for a key that was not understood MUST be key=NotUnderstood. Text operations are usually meant for parameter setting/negotiations but can be used also to perform some active operations. It is recommended that Text operations that will take a long time should be placed in their own Text command. A session may have only one outstanding text command at any given time. Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" on 13-06-2001 20:09:18 Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Eddy Quicksall'" , Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: All text keys MUST be supported? I interpret 2.8.3 to mean "an iSCSI implementation is REQUIRED to recognize and answer all text keys specified in the iSCSI protocol document. Some features negotiated with these text commands are OPTIONAL to implement." Julian, is that your intention? Would you make the wording more explicit? The further text is implicitly refering to 'proprietary' text keys a vendor may dream up. Marj > -----Original Message----- > From: Eddy Quicksall [mailto:EQuicksall@mediaone.net] > Sent: Tuesday, June 12, 2001 10:20 AM > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > Subject: iSCSI: All text keys MUST be supported? > > > > Section "2.8.3 Text" says: > > All of these keys, except for the X- extension format, > MUST be supported by iSCSI initiators and targets. > > But it further says: > > Any other key not understood by the target may be ignored without > affecting basic function. If the Text Response does not > contain a key > that was requested, the initiator must assume that the key was not > understood by the target or, whenever appropriate, that > the response > was "none". > > These two statements seem contradictory (I don't think the > 2nd is talking > about only the X keys). I vote for removing the 1st paragraph above > and going with the 2nd. That way we would not have to insist > that every > key be supported ... the requester would just take the default if the > receiver did not support the key. > > Actually, section "2.9.3 Text Response Data" says: > > If the Text Response does not contain a key that > was requested, the initiator must assume that the key was not > understood by the target or that the answer is =none. > > This seems to backup the 2nd paragraph above. > > > > Eddy@Quicksall.com > From owner-ips@ece.cmu.edu Wed Jun 13 15:03:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29489 for ; Wed, 13 Jun 2001 15:03:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DI6bs20808 for ips-outgoing; Wed, 13 Jun 2001 14:06:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DI6ag20800 for ; Wed, 13 Jun 2001 14:06:36 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA43560 for ; Wed, 13 Jun 2001 13:01:05 -0500 Received: from f3n41e (d03nm041h.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5DI6Y284816 for ; Wed, 13 Jun 2001 12:06:34 -0600 Importance: Normal Subject: iSCSI: Login Question Clarifications To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Kaladhar Voruganti" Date: Wed, 13 Jun 2001 19:06:32 +0100 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/13/2001 11:06:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Julian, I need your help in clarifying the following iSCSI Login questions: 1) When you interleave Login command and Text command messages during the login phase, does the last message from the initiator to the target have to be a Login command message, or can it be also a Text message? 2) The last Login message from the initiator must have the F bit set? 3) During multi-phased login process: a) Does the initiator keep the CmdSn value to be constant (say 1) or does it increase it during each of the login phases (including for the interleaving Text commands)? b) Does the target keep the InitStatSN value to be constant? c) If you have a login command, a text command and then again a login command, then how does the target set the StatSN value and the InitStatSN value? 4) The default value for Max connections is set to 8, and the default value for EnableACA is yes. If the initiator sends a single Login message with the F bit set to 1 (and it does not specifiy these login keys), then this means that the target must support 8 connections per session, and must support ACA. I think that the default values for these two keys should be changed. Are these being changed in Revision 7? Kaladhar From owner-ips@ece.cmu.edu Wed Jun 13 15:14:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29690 for ; Wed, 13 Jun 2001 15:14:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DHS4E17744 for ips-outgoing; Wed, 13 Jun 2001 13:28:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DHS2g17740 for ; Wed, 13 Jun 2001 13:28:03 -0400 (EDT) Received: from HQMailWeb.Crossroads.com [63.237.99.250:25] by va2mc.ummailbox.net with SMTP id G0613-1327-54e201; Wed, 13 Jun 2001 17:27:56 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 13 Jun 2001 12:27:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: iSCSI version 0.6 - Query? Date: Wed, 13 Jun 2001 12:27:49 -0500 Message-ID: Thread-Topic: iSCSI version 0.6 - Query? Thread-Index: AcD0FSVoTeeGZWKdS+mc1y+wIMUJNwAF6/6Q From: "Robert Griswold" To: "Tanjore K. Suresh" , X-OriginalArrivalTime: 13 Jun 2001 17:27:49.0467 (UTC) FILETIME=[2B125AB0:01C0F42E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f5DHS3g17741 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit This is a very good question. If "silently ignore" means that at the time of receipt the target should not attempt to qualify the receipt of the command at the time it received it, but instead attempt to resolve this after the MaxCmdSN has been sent, then I would say it makes sense, but your question interests me with regards to recovery. Since section 6.1 requires Targets to reject PDUs in a session with format errors (assuming a misaligned CmdSN constitutes a format error) then it would seem that this section on page 12 is not in agreement with recovery. But, the recovery section also leaves the door open for Target mode implementation on recovery, so if the paragraph on page 12 over-rides the recovery section, it must be up to the implementer of the Target to attempt to recover such a misaligned command? Bob Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: Tanjore K. Suresh [mailto:Tanjore.Suresh@Sun.COM] Sent: Sunday, June 10, 2001 12:26 AM To: ips@ece.cmu.edu Subject: iSCSI version 0.6 - Query? Hi, Page 12, Last paragraph. Regarding the command sequence number. " The target MUST silently *ignore* any command outside this range or duplicates with in the range that have not been flagged with the retry bit (the X bit in the opcode)" Why ignore commands which are not in the expected range or duplicates with in the range? This type of ignoring could cause initator to cause some unnecessary recovery activity which could/may end up to be not good for the target which is hale and healthy. Such a command could have been errorneously numbered or errorneously checked for this condition or errnoneously delivered with sequence number change because of problems transporting it over the internet fabric. Hence, my opinion is appropriate error need to be returned for such command instead of ignoring. Comments? Thanks sureshtk I From owner-ips@ece.cmu.edu Wed Jun 13 15:15:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29734 for ; Wed, 13 Jun 2001 15:15:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DH9Ol16379 for ips-outgoing; Wed, 13 Jun 2001 13:09:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DH9Mg16374 for ; Wed, 13 Jun 2001 13:09:23 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel2.hp.com (Postfix) with ESMTP id 5D4E01900; Wed, 13 Jun 2001 13:09:22 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id D49C01F50C; Wed, 13 Jun 2001 13:08:53 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 13:09:21 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09102@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Eddy Quicksall'" , julian_satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: All text keys MUST be supported? Date: Wed, 13 Jun 2001 13:09:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I interpret 2.8.3 to mean "an iSCSI implementation is REQUIRED to recognize and answer all text keys specified in the iSCSI protocol document. Some features negotiated with these text commands are OPTIONAL to implement." Julian, is that your intention? Would you make the wording more explicit? The further text is implicitly refering to 'proprietary' text keys a vendor may dream up. Marj > -----Original Message----- > From: Eddy Quicksall [mailto:EQuicksall@mediaone.net] > Sent: Tuesday, June 12, 2001 10:20 AM > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > Subject: iSCSI: All text keys MUST be supported? > > > > Section "2.8.3 Text" says: > > All of these keys, except for the X- extension format, > MUST be supported by iSCSI initiators and targets. > > But it further says: > > Any other key not understood by the target may be ignored without > affecting basic function. If the Text Response does not > contain a key > that was requested, the initiator must assume that the key was not > understood by the target or, whenever appropriate, that > the response > was "none". > > These two statements seem contradictory (I don't think the > 2nd is talking > about only the X keys). I vote for removing the 1st paragraph above > and going with the 2nd. That way we would not have to insist > that every > key be supported ... the requester would just take the default if the > receiver did not support the key. > > Actually, section "2.9.3 Text Response Data" says: > > If the Text Response does not contain a key that > was requested, the initiator must assume that the key was not > understood by the target or that the answer is =none. > > This seems to backup the 2nd paragraph above. > > > > Eddy@Quicksall.com > From owner-ips@ece.cmu.edu Wed Jun 13 16:57:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01480 for ; Wed, 13 Jun 2001 16:57:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DJHrp26476 for ips-outgoing; Wed, 13 Jun 2001 15:17:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DI26g20415 for ; Wed, 13 Jun 2001 14:02:07 -0400 (EDT) Received: from smui04.slb.mindspring.net (smui04.slb.mindspring.net [199.174.114.26]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA14882 for ; Wed, 13 Jun 2001 14:02:06 -0400 (EDT) From: ljlamers@mindspring.com Received: by smui04.slb.mindspring.net id OAA0000005384; Wed, 13 Jun 2001 14:02:06 -0400 (EDT) Date: Wed, 13 Jun 2001 14:02:06 -0400 To: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Message-ID: X-Originating-IP: 216.172.186.100 Sender: owner-ips@ece.cmu.edu Precedence: bulk Modified SLP should be the mandatory to implement. SendTargets is allowed under a grandfather agreement since it is out there and should be carried in an Annex with a clear notation that it is obsolete and is there because of pre-standard implementations. There is no need to mention iSNS - that is pretty nearly a vendor specific approach to solving their perception of a problem, open source available or not. At 06/12/2001, Jim Hafner wrote: Folks, I think this thread is wandering off the field. The question is the issue of SendTargets. Let's remind ourselves of the original purpose of this proposed protocol: namely, it's designed for a storage box that contains one or more iSCSI target devices to report about ITSELF, about what's in it! This includes both a list of the iSCSI targets it has PLUS the session coordination (via tags) of the various IPaddress/tcpport combos it supports. In other words, it's job is to report about itself! The use of (unicast) SLP as an alternative to SendTargets was focused exactly on the same question: I ask a single box to tell me about itself. This function lies between the two extremes of (a) static configuration of initiators and (b) centralized management via iSNS style services. Somehow, someway, we need to define a protocol for a box to "tell us about itself" in the absense of the centralized management infrastructure. That seems critical to me. Even if I want to do static configuration, the guy doing the configuration needs a way to get at the guts of each new box he/she rolls into the environment. The choices are, it seems, that *every* box would need to support at least one of: a) SendTargets b) modified SLP c) iSNS What's the consensus on the protocol we aim for to solve this middle ground discovery problem? Jim Hafner From owner-ips@ece.cmu.edu Wed Jun 13 16:57:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01492 for ; Wed, 13 Jun 2001 16:57:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DJIK726508 for ips-outgoing; Wed, 13 Jun 2001 15:18:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DHUSg17919 for ; Wed, 13 Jun 2001 13:30:28 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id TAA180838 for ; Wed, 13 Jun 2001 19:30:21 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5DHSsF22172 for ; Wed, 13 Jun 2001 19:28:54 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A6A.0060093D ; Wed, 13 Jun 2001 19:28:58 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 13 Jun 2001 20:32:03 +0300 Subject: RE: iSCSI: All text keys MUST be supported? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk 1.2.4 reads now: 1.1.1 Text Mode Negotiation During login and thereafter some session or connection parameters are negotiated through an exchange of textual information. In "list" negotiation, the offering party sends a list of values for a key in its order of preference. The responding party answers with the first value from the list it supports and is allowed to use for the specific initiator. The value "none" MUST always be used to indicate a missing function. However, none is a valid selection only if it is explicitly offered and MAY be selected by omission (i.e., =none MAY be omitted). If a target is not supporting, or not allowed to use with a specific initiator, any of the offered options, it may use the value "reject". The values "none" and "reject" are reserved and must be used only as described here. Any key not understood is answered with "NotUnderstood". The general format of text negotiation is: Offer-> =,,..., Answer-> =|reject|NotUnderstood In "numerical" negotiations, the offering and responding party state a numerical value. The result of the negotiation is key dependent; frequently the lower or the higher of the two values is used. Although the initiator is the requesting party and controls the request-response initiation and termination the target can offer key=value pairs of its own as part of a sequence and not only in response to an identical key=value pair offered by the initiator. And 2.8.3 reads: 1.1.1 Text The initiator sends the target a set of key=value or key=list pairs encoded in UTF-8 Unicode. The key and value are separated by a '=' (0x3D) delimiter. Many key=value pairs can be included in the Text block by separating them with null (0x00) delimiters. A list is a set of values separated by comma (0x2C). Large binary items can be encoded using their hexadecimal representation (e.g., 8190 is 0x1FFE) or decimal representation. The maximum length of an individual value (not its string representation) is 255 bytes. The data length of a text command or response SHOULD be less than 4096 bytes. Key names MUST NOT exceed 64 bytes. Key values MUST NOT exceed 255 characters. Character strings are represented as plain text. Numeric and binary values are represented using either decimal numbers or the hexadecimal 0x'ffff' notation. The result is adjusted to the specific key. The target responds by sending its response back to the initiator. The response text format is similar to the request text format. Some basic key=value pairs are described in Appendix A and D. All of these keys, except for the X- extension format, MUST be supported by iSCSI initiators and targets. Manufacturers may introduce new keys by prefixing them with X- followed by their (reversed) domain name, for example the company owning the domain acme.com can issue: X-com.acme.bar.foo.do_something=0000000000000003 Any other key not understood by the target may be ignored by the target without affecting basic function. However the Text Response for a key that was not understood MUST be key=NotUnderstood. Text operations are usually meant for parameter setting/negotiations but can be used also to perform some active operations. It is recommended that Text operations that will take a long time should be placed in their own Text command. A session may have only one outstanding text command at any given time. Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" on 13-06-2001 20:09:18 Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Eddy Quicksall'" , Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: All text keys MUST be supported? I interpret 2.8.3 to mean "an iSCSI implementation is REQUIRED to recognize and answer all text keys specified in the iSCSI protocol document. Some features negotiated with these text commands are OPTIONAL to implement." Julian, is that your intention? Would you make the wording more explicit? The further text is implicitly refering to 'proprietary' text keys a vendor may dream up. Marj > -----Original Message----- > From: Eddy Quicksall [mailto:EQuicksall@mediaone.net] > Sent: Tuesday, June 12, 2001 10:20 AM > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > Subject: iSCSI: All text keys MUST be supported? > > > > Section "2.8.3 Text" says: > > All of these keys, except for the X- extension format, > MUST be supported by iSCSI initiators and targets. > > But it further says: > > Any other key not understood by the target may be ignored without > affecting basic function. If the Text Response does not > contain a key > that was requested, the initiator must assume that the key was not > understood by the target or, whenever appropriate, that > the response > was "none". > > These two statements seem contradictory (I don't think the > 2nd is talking > about only the X keys). I vote for removing the 1st paragraph above > and going with the 2nd. That way we would not have to insist > that every > key be supported ... the requester would just take the default if the > receiver did not support the key. > > Actually, section "2.9.3 Text Response Data" says: > > If the Text Response does not contain a key that > was requested, the initiator must assume that the key was not > understood by the target or that the answer is =none. > > This seems to backup the 2nd paragraph above. > > > > Eddy@Quicksall.com > From owner-ips@ece.cmu.edu Wed Jun 13 16:57:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01503 for ; Wed, 13 Jun 2001 16:57:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DJHZ126462 for ips-outgoing; Wed, 13 Jun 2001 15:17:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DI51g20645 for ; Wed, 13 Jun 2001 14:05:01 -0400 (EDT) Received: from eddylaptop (h00e098880aa4.ne.mediaone.net [66.31.75.244]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f5DI50615792 for ; Wed, 13 Jun 2001 14:05:00 -0400 (EDT) From: "Eddy Quicksall" To: Subject: RE: iSCSI: All text keys MUST be supported? Date: Wed, 13 Jun 2001 14:05:01 -0400 Message-ID: <007d01c0f433$5df9b810$b101a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87802A09102@xrose06.rose.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, but it would be more general if we could go with 2.9.3 because it would let us use defaults when new keys are invented but not yet supported. Actually, if keys are "OPTIONAL to implement" then one would send =reject if not implemented. So, that would mean that the key could also be not recognized and one could send =reject (contradicting the "REQUIRED to recognize). Given that, why say they are "REQUIRED to recognize"? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Wednesday, June 13, 2001 1:09 PM To: 'Eddy Quicksall'; julian_satran@il.ibm.com; ips@ece.cmu.edu Subject: RE: iSCSI: All text keys MUST be supported? I interpret 2.8.3 to mean "an iSCSI implementation is REQUIRED to recognize and answer all text keys specified in the iSCSI protocol document. Some features negotiated with these text commands are OPTIONAL to implement." Julian, is that your intention? Would you make the wording more explicit? The further text is implicitly refering to 'proprietary' text keys a vendor may dream up. Marj > -----Original Message----- > From: Eddy Quicksall [mailto:EQuicksall@mediaone.net] > Sent: Tuesday, June 12, 2001 10:20 AM > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > Subject: iSCSI: All text keys MUST be supported? > > > > Section "2.8.3 Text" says: > > All of these keys, except for the X- extension format, > MUST be supported by iSCSI initiators and targets. > > But it further says: > > Any other key not understood by the target may be ignored without > affecting basic function. If the Text Response does not > contain a key > that was requested, the initiator must assume that the key was not > understood by the target or, whenever appropriate, that > the response > was "none". > > These two statements seem contradictory (I don't think the > 2nd is talking > about only the X keys). I vote for removing the 1st paragraph above > and going with the 2nd. That way we would not have to insist > that every > key be supported ... the requester would just take the default if the > receiver did not support the key. > > Actually, section "2.9.3 Text Response Data" says: > > If the Text Response does not contain a key that > was requested, the initiator must assume that the key was not > understood by the target or that the answer is =none. > > This seems to backup the 2nd paragraph above. > > > > Eddy@Quicksall.com > From owner-ips@ece.cmu.edu Wed Jun 13 17:03:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01621 for ; Wed, 13 Jun 2001 17:03:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DJA5d25836 for ips-outgoing; Wed, 13 Jun 2001 15:10:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DJA3g25831 for ; Wed, 13 Jun 2001 15:10:03 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 15:11:45 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0708015683@corpmx9.isus.emc.com> From: Black_David@emc.com To: cbm@rose.hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: statement on mandatory/optional Date: Wed, 13 Jun 2001 15:09:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, I think we're in basic agreement. > In general, you suggest that the level of requirement specification > should be at least at the section level - than at the beginning > of the document. I am okay with that. Yes -- a general piece of advice is to use the terms defined in RFC 2119, and use them in places close enough to the specification of the features that someone looking for the feature is unlikely to miss the corresponding requirement statement(s). Summaries by section are fine if they improve clarity/readability/accessibility of the document. > Would the following wording express what I wanted better, say for > digests? > > Receivers are REQUIRED to support digests and senders MAY use > digests. > > than the current > "and MUST be implemented by every iSCSI initiator and target." in rev06. I don't think so, because the shift from "initiator/target" to "sender/receiver" terminology implies that the digests are separately negotiated in each direction which is not the current state of things. Going back to the former terminology is better: Targets are REQUIRED to support digests and initiators MAY use digests. although it needs some additional text describing the negotiation - if the Initiator sends a Digest key indicating that presence of the digest is the only acceptable alternative (i.e., "none" is not offered), the Target MUST accept this, and then in full-feature phase, both the Initiator and Target MUST generate and check the negotiated digest in both directions. Note that this is weaker than one of the possible intentions of the -06 text, namely that either side can require through negotiation that digests be used, in which case different language is needed. > I agree with your suggestion to use REQUIRED for "not implemented" > and the negotiation itself where appropriate - this also implies to me > that the "base" functionality support is not necessarily REQUIRED when > an implementation supports a feature defined as OPTIONAL. > > If this is true, I suggest to Julian that language be added for synch > and steering to make the no sync-and-steering mode REQUIRED, in addition > to stating that synch and steering is OPTIONAL. In general, I think that if feature is OPTIONAL, correct (inter-)operation in the absence of is REQUIRED, but spelling that out for clarity doesn't hurt. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jun 13 18:56:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03058 for ; Wed, 13 Jun 2001 18:56:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DLm6o07910 for ips-outgoing; Wed, 13 Jun 2001 17:48:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DLJHg05715 for ; Wed, 13 Jun 2001 17:19:17 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel2.hp.com (Postfix) with ESMTP id 4083F1905 for ; Wed, 13 Jun 2001 14:19:16 -0700 (PDT) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 729601F50D for ; Wed, 13 Jun 2001 08:16:22 -0700 (PDT) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 14:19:15 -0700 Message-ID: From: "NELSON,DEAN (HP-Boise,ex1)" To: "'ips@ece.cmu.edu'" Date: Wed, 13 Jun 2001 14:19:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0F44E.7EB76AF0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0F44E.7EB76AF0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F44E.7EB76AF0" ------_=_NextPart_001_01C0F44E.7EB76AF0 Content-Type: text/plain; charset="iso-8859-1" subscribe ips _____ Dean Nelson R&D Software Engineer MNS - Modular Network Storage 11311 Chinden Blvd., MS 833 Boise, ID 83714 Ph: (208) 396-7903 dean_nelson@hp.com _____ ------_=_NextPart_001_01C0F44E.7EB76AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

subscribe ips

 

=

<= font color=3Dblack>=

=

Dean Nelson=

R&D Software Engineer

MNS - Modular Network Storage
11311 Chinden Blvd., MS 833
Boise, ID  83714
Ph: (208) 396-7903  dean_nelson@hp.com<= font color=3Dblack>=

 

 =

 =

------_=_NextPart_001_01C0F44E.7EB76AF0-- ------_=_NextPart_000_01C0F44E.7EB76AF0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="image001.gif" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhSgA9APQAACtPjf///83NzY6aruXm56iyxExMTFtznQ8PD77EzdbW2Ao1fvPz9N7e3wAA AAAAAAECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAyH/C01T T0ZGSUNFOS4wGAAAAAxtc09QTVNPRkZJQ0U5LjAQAiDF3gAh/wtNU09GRklDRTkuMBgAAAAMY21Q UEpDbXAwNzEyAAAAB09tt6UALAAAAABKAD0AAAT/MIQClr0469saqF/DHFtpYsBASGxAnvA1CAV2 KEoV77bAsAleLKF4WQqKmnA5a0h0S82hIBBAAdUGLjE4QKMarOIHzkyrikFvzGIQGgVj2YIVrOaW mQBHkBOdLRIMDAJyYHVOcwBIeyIMV3s/gS0MSmWIDJeMCgQ/lgszbJOBVpdZmWCMDSsSfgKAo4Ee h6epaKwBDWuSsYEKtK+oQgd7nC2foby9x1GYSwAJe50tfsbLo4YwzkIDCsEtvxfEoteyX9q1QtHW LGoXAAfxKm3x9fYJ7ULbO8SRgecoAAUxMS/cjn0xurGTYHDBhy9IXKD4QmwFwBIIT9QhJ8FdniIY /6g0vFHKAjEnnzSmiwHAmwhKV3DEpIGhm0dQCpw0VBmMB0lcEgZ+/NTPlZE6Kx4dXAnjxsIAN6nI oSJ0wY2qTiVdDMP0xDhlBCCVdFjlps2Qr1hk25CRoD8WyGjK2AMJJB1papf25Pe2FYZoUwVgTbIr L8uuJrK2gdJvppxu1WBJPLw3xle4NQWY9RZzFh1vuJRSFsFDDK8rgN9FixuXnGh0lWFL0iVOwWC7 R3AvQCK5Kk/SPLqx2mxW8EzGoFvc/C3MctoR76qg1ozCS2bXW7nGjoGEUA+i3taqztnCN/MlNwZp KUAlS5L2Ca7Yi7cOqHi2iDUSkfCmw6oADPgHR/9N0VRRTE68mHceemwM4uAPD0J3ARE5CTgNC9nh t90OA0gWC20mVcGKMvk8kx93JE6CDA4pYtbMidoU0KJhFkTjITPAAHdIAb2MxEcsKekDI4ctRtUX C33g0VYz+PwTHXmUDJDhaK/hMQUrPtohiGZT6iXCfWAIABVaBQzQRZdCBqPgJZygUAWYeHTzzXJz nCWDbXh4hQYsCczn559+RtOFF2fEAeihiMbT3iuheWPgo5BGKikBBDiKIICSZqpppJyAhcOnoIYq qqgBgspKpaOmqiqoq6ToBqWwxirrrLECGKskr9Kq666wDlLOr8AGK+ywxBZr7LHIJqvsssw26+yl s9BGe+wAPEprbSAMOGDAtcr2OSNcTXJ77AEI3BiItqM4cIABCCAAFH/oDuDAAJOM0G61k6jLrruT COCAAwhcg26+CAzALr2THOCAAOyOIm8D5LYIsMEF12uAA/jGgsC2+W5LgLqjNKDtvKNc/O/C6XoM 8iQPC8zxuduKPECLF/ObMAKaZdwCujKnqLC5LWw8itAiHxBLAitb3C7CkxCddBstTxIBADs= ------_=_NextPart_000_01C0F44E.7EB76AF0-- From owner-ips@ece.cmu.edu Wed Jun 13 18:57:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03070 for ; Wed, 13 Jun 2001 18:57:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DL3IV04532 for ips-outgoing; Wed, 13 Jun 2001 17:03:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailsys01.intnet.net (antares.intnet.net [198.252.32.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DL3Hg04528 for ; Wed, 13 Jun 2001 17:03:17 -0400 (EDT) Received: from [207.90.20.22] (HELO borg2) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with SMTP id 9731570 for ips@ece.cmu.edu; Wed, 13 Jun 2001 17:01:43 -0400 Message-ID: <05e601c0f44c$26049420$0201a8c0@borg2> From: "Jon William Toigo" To: Subject: Questions about FCIP Date: Wed, 13 Jun 2001 17:02:25 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05E3_01C0F42A.9EC9C140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_05E3_01C0F42A.9EC9C140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To any kind persons (and even unkind ones), I am looking for a few = answers that I am not seeing addressed in standards docs on-line. = Hopefully, someone has a few answers to the following questions: 1. Where does the FCIP protocol spec stand at present? Has it been = moved up the food chain for ratification? If not, is there any thinking = on when this will happen? 2. Are there any reasons or situations in which FCIP might be = considered preferable to iFCP? What are its strengths? 3. How is FC SAN node addressing handled in a multi-"island" SAN = interconnected by FCIP links? 4. How are IP performance problems handled in FCIP? Is radical = reconstruction required each time an IP network-related interruption = occurs? 5. Where will the heavy lifting of FCIP (the encapsulation of the data = for transmission through the tunnel) be implemented? On the FC switch = blade? on an IP switch or router blade? On some third party device? = Are their different implementations? Any benefits or drawbacks of each? Thanks in advance. Jon William Toigo Independent Consultant and Author jtoigo@intnet.net ------=_NextPart_000_05E3_01C0F42A.9EC9C140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
To any kind persons (and even unkind = ones), I am=20 looking for a few answers that I am not seeing addressed in standards = docs=20 on-line.  Hopefully, someone has a few answers to the following=20 questions:
 
1.  Where does the FCIP protocol = spec stand at=20 present?  Has it been moved up the food chain for = ratification?  If=20 not, is there any thinking on when this will = happen?

2.  Are=20 there any reasons or situations in which FCIP might be=20 considered preferable to iFCP?  What are its=20 strengths?

3.  How is FC SAN node addressing handled in a=20 multi-"island" SAN interconnected by FCIP links?

4.  How are = IP=20 performance problems handled in FCIP?  Is radical reconstruction = required=20 each time an IP network-related interruption = occurs?

5.  Where=20 will the heavy lifting of FCIP (the encapsulation of the data for = transmission=20 through the tunnel) be implemented?  On the FC switch blade? on an = IP=20 switch or router blade?  On some third party device?  Are=20 their
different implementations?  Any benefits or drawbacks of=20 each?

Thanks in advance.

Jon William Toigo
Independent=20 Consultant and Author
jtoigo@intnet.net

------=_NextPart_000_05E3_01C0F42A.9EC9C140-- From owner-ips@ece.cmu.edu Wed Jun 13 19:07:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03201 for ; Wed, 13 Jun 2001 19:07:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DLlsG07884 for ips-outgoing; Wed, 13 Jun 2001 17:47:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from spectrum2.osicom.com (spectrum2.osicom.com [131.143.8.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DLKTg05845 for ; Wed, 13 Jun 2001 17:20:29 -0400 (EDT) Received: from aj-mail.aj.osicom.com (aj-mail.aj.entradanet.com [131.143.44.5]) by spectrum2.osicom.com (8.9.2/8.9.2) with ESMTP id RAA13446 for ; Wed, 13 Jun 2001 17:21:23 -0400 (EDT) Received: by aj-mail.aj.entradanet.com with Internet Mail Service (5.5.2448.0) id ; Wed, 13 Jun 2001 17:19:56 -0400 Message-ID: From: "Harmon, Robert" To: "Ips (E-mail)" Subject: Common Encapsulation: CRC at beginning of frame? Date: Wed, 13 Jun 2001 17:19:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F44E.97C3BBAC" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F44E.97C3BBAC Content-Type: text/plain; charset="windows-1252" Has there been any discussion of putting the common encapsulation CRC at the end of the frame rather than -near- the beginning? Its possible to do CRC in H/W but to put it at the beginning of the frame is 5 times harder than putting it at the end. ------_=_NextPart_001_01C0F44E.97C3BBAC Content-Type: text/html; charset="windows-1252" Common Encapsulation: CRC at beginning of frame?

Has there been any discussion of putting the
common encapsulation CRC at the end of the frame
rather than -near- the beginning?

Its possible to do CRC in H/W but to put it at the
beginning of the frame is 5 times harder than putting
it at the end.

------_=_NextPart_001_01C0F44E.97C3BBAC-- From owner-ips@ece.cmu.edu Wed Jun 13 20:54:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03997 for ; Wed, 13 Jun 2001 20:54:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DNQAg14732 for ips-outgoing; Wed, 13 Jun 2001 19:26:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailsys01.intnet.net (antares.intnet.net [198.252.32.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DNQ9g14728 for ; Wed, 13 Jun 2001 19:26:09 -0400 (EDT) Received: from [207.90.20.22] (HELO borg2) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with SMTP id 9746721; Wed, 13 Jun 2001 19:25:11 -0400 Message-ID: <063b01c0f460$2c73d3c0$0201a8c0@borg2> From: "Jon William Toigo" To: , References: <0F31E5C394DAD311B60C00E029101A0708015687@corpmx9.isus.emc.com> Subject: Re: Questions about FCIP Date: Wed, 13 Jun 2001 19:25:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Apologies to David and all if my questions moved outside appropriate boundaries for the group. It was not my intention to encourage food fights or other forms of disorder. JWT "Just Call Me A Troublemaker" ----- Original Message ----- From: To: ; Sent: Wednesday, June 13, 2001 7:21 PM Subject: RE: Questions about FCIP > Note that the purpose of this list is discussion of specification > and standardization issues surrounding IP Storage protocols. Some > of Jon's questions should be discussed in some forum other than this > list. > > > 1. Where does the FCIP protocol spec stand at present? Has it been moved > up the food chain for ratification? > > If not, is there any thinking on when this will happen? > > It's an Internet-Draft. The IPS WG charter currently has a goal of > September for completion. This may change > as the WG charter is revised over the summer. > > > 2. Are there any reasons or situations in which FCIP might be considered > preferable to iFCP? What are > > its strengths? > > We've already had one food fight on this topic on the list - let's not do > that again. Those with opinions > or comments on this should send them directly to Jon - please DO NOT reply > to or discuss this on the list. > > > 3. How is FC SAN node addressing handled in a multi-"island" SAN > interconnected by FCIP links? > > An FCIP link looks like an inter-switch link as far as Fibre Channel is > concerned, so addressing works > in the same fashion as if everything were Fibre Channel. > > > 4. How are IP performance problems handled in FCIP? Is radical > reconstruction required each time an > > IP network-related interruption occurs? > > FCIP runs over TCP. If all the TCP connections for a link close, the > inter-switch link is down and FC takes > whatever action is appropriate. How radical that would be depends on the > topology at the FC level. > > > 5. Where will the heavy lifting of FCIP (the encapsulation of the data > for transmission through the tunnel) be > > implemented? On the FC switch blade? on an IP switch or router blade? On > some third party device? Are > > their different implementations? Any benefits or drawbacks of each? > > This one is at best borderline for discussion on this list, especially if > it turns into a "beauty contest" over who has the best implementation > approach/architecture. Please send any replies/comments directly to Jon > and DO NOT reply or discuss this on the list. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Wed Jun 13 20:55:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04017 for ; Wed, 13 Jun 2001 20:55:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DNMuL14513 for ips-outgoing; Wed, 13 Jun 2001 19:22:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DNMtg14508 for ; Wed, 13 Jun 2001 19:22:55 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 16:22:48 -0700 Message-ID: From: Charles Monia To: "'Harmon, Robert'" Cc: "Ips (E-mail)" Subject: RE: Common Encapsulation: CRC at beginning of frame? Date: Wed, 13 Jun 2001 16:22:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Robert: The CRC you refer to only covers the encapsulation header, not the FC Frame, which is covered by its own, separately computed FC CRC. According to section 2.1 on pp 6:: "CRC (word 6): When the CRCV Flag bit is zero, the CRC field SHALL contain zero. When the CRCV Flag bit is one, the CRC field SHALL contain a CRC for words 0 to 5 of the FC Encapsulation Header computed using the polynomial, initial value, and bit order defined for Fibre Channel[3]." Charles -----Original Message----- From: Harmon, Robert [mailto:rharmon@entradanet.com] Sent: Wednesday, June 13, 2001 2:20 PM To: Ips (E-mail) Subject: Common Encapsulation: CRC at beginning of frame? Has there been any discussion of putting the common encapsulation CRC at the end of the frame rather than -near- the beginning? Its possible to do CRC in H/W but to put it at the beginning of the frame is 5 times harder than putting it at the end. From owner-ips@ece.cmu.edu Wed Jun 13 20:55:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04029 for ; Wed, 13 Jun 2001 20:55:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DNLi014440 for ips-outgoing; Wed, 13 Jun 2001 19:21:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DNLig14436 for ; Wed, 13 Jun 2001 19:21:44 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 19:20:45 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A0708015687@corpmx9.isus.emc.com> From: Black_David@emc.com To: jtoigo@IntNet.net, ips@ece.cmu.edu Subject: RE: Questions about FCIP Date: Wed, 13 Jun 2001 19:21:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Note that the purpose of this list is discussion of specification and standardization issues surrounding IP Storage protocols. Some of Jon's questions should be discussed in some forum other than this list. > 1. Where does the FCIP protocol spec stand at present? Has it been moved up the food chain for ratification? > If not, is there any thinking on when this will happen? It's an Internet-Draft. The IPS WG charter currently has a goal of September for completion. This may change as the WG charter is revised over the summer. > 2. Are there any reasons or situations in which FCIP might be considered preferable to iFCP? What are > its strengths? We've already had one food fight on this topic on the list - let's not do that again. Those with opinions or comments on this should send them directly to Jon - please DO NOT reply to or discuss this on the list. > 3. How is FC SAN node addressing handled in a multi-"island" SAN interconnected by FCIP links? An FCIP link looks like an inter-switch link as far as Fibre Channel is concerned, so addressing works in the same fashion as if everything were Fibre Channel. > 4. How are IP performance problems handled in FCIP? Is radical reconstruction required each time an > IP network-related interruption occurs? FCIP runs over TCP. If all the TCP connections for a link close, the inter-switch link is down and FC takes whatever action is appropriate. How radical that would be depends on the topology at the FC level. > 5. Where will the heavy lifting of FCIP (the encapsulation of the data for transmission through the tunnel) be > implemented? On the FC switch blade? on an IP switch or router blade? On some third party device? Are > their different implementations? Any benefits or drawbacks of each? This one is at best borderline for discussion on this list, especially if it turns into a "beauty contest" over who has the best implementation approach/architecture. Please send any replies/comments directly to Jon and DO NOT reply or discuss this on the list. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jun 13 20:57:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04044 for ; Wed, 13 Jun 2001 20:57:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DNCvo13825 for ips-outgoing; Wed, 13 Jun 2001 19:12:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from server1.NishanSystems.COM (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DNCtg13820 for ; Wed, 13 Jun 2001 19:12:55 -0400 (EDT) Received: by smtp.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 16:12:49 -0700 Message-ID: From: Charles Monia To: "Ips (E-mail)" Subject: RE: iFCP implementation doubts Date: Wed, 13 Jun 2001 16:12:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > -----Original Message----- > From: Sathya [mailto:n.sathya@gdatech.co.in] > Sent: Wednesday, June 13, 2001 6:22 AM > To: ips@ece.cmu.edu > Cc: sathya > Subject: iFCP implementation doubts > > > > Hi all, > I am working on iFCP/FCIP implementation for bringing up a > LAN -SAN Switch. I have some doubts on the iFCP protocol > implementation > > > The iFCp document specifies a Switch topology for connecting > the iFCP gateway , the master Switch and the FC elements. Is > this topology a mandatory or can we go with a FC-AL configuration ? > Hi Sathya: There are no restrictions on the FC fabric topologies that an iFCP gateway can support, so a gateway implementation can support loops as well as switches. The switch topology shown in the spec is simply a convenient example, intended to show the transition from a fibre channel fabric to an IP fabric. (Since this issue has come up before, I believe it's worthwhile to discuss alternate FC topologies in an appendix to the iFCP spec.) > > If Switch Topology: > > 1. what shall be the interaction between the iFCP gateway and > the Principal switch in terms of FC Domain address and N port > ID assignments? > If the iFCP gateway is operating in address translation mode as part of a switched environment, then it simply receives its domain I/D from the Principle Switch. > 2. Is it possible for a iFCP GW and the FC Switch (Master) to > have transactions other than via the E-port > Yes -- Another way is to emulate a hub, and present the FC devices as shown below. +----------+ +-------+ +------+FL FC- | FL Port | | iFCP | IP | iFCP +<----->AL | +<-FC->+ GW +-----+ GW |Port +----------+ AL | |Cloud| | +-------+ | |FL FC- | +<----->AL | |Port +------+ In the above topology, the left-hand iFCP GW presents the remote devices as loop-attached NL_PORTs attached to the FL port. +----------+ +-------+ +------+NL FC- | NL Ports | | iFCP | | iFCP +<----->AL | +<-FC->+ GW1 +--IP Cloud---+ GW2 |Port +----------+ AL | | | | +-------+ | |NL FC- | +<----->AL | |Port +------+ In this alternative topology, GW1 and GW2 present remote devices as NL_PORTs attached to a local loop. Once again, these are examples and other configurations are possible. > 3. Or the iFCP GW can take the functionality of even the > Principal switch? > Yes. > 4. For an existing iFCP network will it be possible to add > the iFCP gateway If so what will be the methods to handle > the already assigned addresses without any conflict.? > In address translation mode, there should be no problem in gracefully adding an iFCP gateway, since the scope of the N_PORT addresses for locally attached devices is restricted to the GW. > If FC-AL Topology: ----- (if it is allowed by the iFCP ) > > 1. Can we have the iFCP GW as the Loop Master in the FC-AL > and the FC Switch as one of the loop element? > Yes -- as described above, a gateway can implement either role in a loop topology. I assume the case you refer to above is one in which the FC switch element implements logical loop behavior by representing switch-attached devices as though they were connected to an FC-AL loop. > 2. If (1) is allowed then whether the Domain ID assignment > for the FC Switch is controlled by the iFCP GW or the > Switch can have its own domain ( i.e. ) the switch can be > independent on maintaining its FC domain by having a separate > iSNS Server as a repository for IDs. > > I'm not sure I understand the question. As an FL port, the gateway would, of course, be in charge of domain ID assignment, in which case, it could then choose to operate in address-transparent mode and obtain its domain id from the iSNS server. Charles From owner-ips@ece.cmu.edu Wed Jun 13 20:57:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04055 for ; Wed, 13 Jun 2001 20:57:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5DNU7D14970 for ips-outgoing; Wed, 13 Jun 2001 19:30:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe12.law11.hotmail.com [64.4.16.116]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DNU6g14966 for ; Wed, 13 Jun 2001 19:30:06 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Jun 2001 16:30:00 -0700 X-Originating-IP: [66.31.75.244] From: "Eddy Quicksall" To: Cc: References: Subject: Re: iSCSI: All text keys MUST be supported? Date: Wed, 13 Jun 2001 19:30:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 13 Jun 2001 23:30:00.0221 (UTC) FILETIME=[C39C44D0:01C0F460] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Looks good, but what about 2.9.3? Should that have the following statement removed? Because you could use that fact to just ignore the key if you don't understand it. If the statement stands, one would have to wonder what the original intent was. 2.9.3 says: If the Text Response does not contain a key that was requested, the initiator must assume that the key was not understood by the target or that the answer is =none. Eddy ----- Original Message ----- From: To: Sent: Wednesday, June 13, 2001 1:32 PM Subject: RE: iSCSI: All text keys MUST be supported? > > > 1.2.4 reads now: > > 1.1.1 Text Mode Negotiation > > During login and thereafter some session or connection parameters are > negotiated through an exchange of textual information. > > In "list" negotiation, the offering party sends a list of values for a > key in its order of preference. > > The responding party answers with the first value from the list it > supports and is allowed to use for the specific initiator. > > The value "none" MUST always be used to indicate a missing function. > However, none is a valid selection only if it is explicitly offered and > MAY be selected by omission (i.e., =none MAY be omitted). > > If a target is not supporting, or not allowed to use with a specific > initiator, any of the offered options, it may use the value "reject". > The values "none" and "reject" are reserved and must be used only as > described here. Any key not understood is answered with > "NotUnderstood". > > The general format of text negotiation is: > > Offer-> =,,..., > Answer-> =|reject|NotUnderstood > > In "numerical" negotiations, the offering and responding party state a > numerical value. The result of the negotiation is key dependent; > frequently the lower or the higher of the two values is used. > > Although the initiator is the requesting party and controls the > request-response initiation and termination the target can offer > key=value pairs of its own as part of a sequence and not only in > response to an identical key=value pair offered by the initiator. > > > And 2.8.3 reads: > > 1.1.1 Text > > The initiator sends the target a set of key=value or key=list pairs > encoded in UTF-8 Unicode. The key and value are separated by a '=' > (0x3D) delimiter. Many key=value pairs can be included in the Text block > by separating them with null (0x00) delimiters. A list is a set of > values separated by comma (0x2C). Large binary items can be encoded > using their hexadecimal representation (e.g., 8190 is 0x1FFE) or decimal > representation. The maximum length of an individual value (not its > string representation) is 255 bytes. > > The data length of a text command or response SHOULD be less than 4096 > bytes. Key names MUST NOT exceed 64 bytes. Key values MUST NOT exceed > 255 characters. > > Character strings are represented as plain text. Numeric and binary > values are represented using either decimal numbers or the hexadecimal > 0x'ffff' notation. The result is adjusted to the specific key. > > The target responds by sending its response back to the initiator. The > response text format is similar to the request text format. > > Some basic key=value pairs are described in Appendix A and D. All of > these keys, except for the X- extension format, MUST be supported by > iSCSI initiators and targets. > > Manufacturers may introduce new keys by prefixing them with X- followed > by their (reversed) domain name, for example the company owning the > domain acme.com can issue: > > X-com.acme.bar.foo.do_something=0000000000000003 > > Any other key not understood by the target may be ignored by the target > without affecting basic function. However the Text Response for a key > that was not understood MUST be key=NotUnderstood. > > Text operations are usually meant for parameter setting/negotiations but > can be used also to perform some active operations. > > It is recommended that Text operations that will take a long time should > be placed in their own Text command. > > A session may have only one outstanding text command at any given time. > > Julo > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" on > 13-06-2001 20:09:18 > > Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" > > > To: "'Eddy Quicksall'" , Julian > Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: RE: iSCSI: All text keys MUST be supported? > > > > > I interpret 2.8.3 to mean "an iSCSI implementation is REQUIRED to recognize > and answer all text keys specified in the iSCSI protocol document. Some > features negotiated with these text commands are OPTIONAL to implement." > > Julian, is that your intention? Would you make the wording more explicit? > > The further text is implicitly refering to 'proprietary' text keys a vendor > may dream up. > > Marj > > > -----Original Message----- > > From: Eddy Quicksall [mailto:EQuicksall@mediaone.net] > > Sent: Tuesday, June 12, 2001 10:20 AM > > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > > Subject: iSCSI: All text keys MUST be supported? > > > > > > > > Section "2.8.3 Text" says: > > > > All of these keys, except for the X- extension format, > > MUST be supported by iSCSI initiators and targets. > > > > But it further says: > > > > Any other key not understood by the target may be ignored without > > affecting basic function. If the Text Response does not > > contain a key > > that was requested, the initiator must assume that the key was not > > understood by the target or, whenever appropriate, that > > the response > > was "none". > > > > These two statements seem contradictory (I don't think the > > 2nd is talking > > about only the X keys). I vote for removing the 1st paragraph above > > and going with the 2nd. That way we would not have to insist > > that every > > key be supported ... the requester would just take the default if the > > receiver did not support the key. > > > > Actually, section "2.9.3 Text Response Data" says: > > > > If the Text Response does not contain a key that > > was requested, the initiator must assume that the key was not > > understood by the target or that the answer is =none. > > > > This seems to backup the 2nd paragraph above. > > > > > > > > Eddy@Quicksall.com > > > > > > From owner-ips@ece.cmu.edu Wed Jun 13 22:50:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06665 for ; Wed, 13 Jun 2001 22:50:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5E0sMR20392 for ips-outgoing; Wed, 13 Jun 2001 20:54:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5E0sLg20387 for ; Wed, 13 Jun 2001 20:54:21 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id 464981869 for ; Wed, 13 Jun 2001 17:54:20 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id RAA02414 for ips@ece.cmu.edu; Wed, 13 Jun 2001 17:55:30 -0700 (PDT) Message-Id: <200106140055.RAA02414@core.rose.hp.com> Subject: iSCSI: comments To: ips@ece.cmu.edu Date: Wed, 13 Jun 2001 17:55:29 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I know that you're close to publishing rev07, but here are some belated comments (sorry!) on rev06. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com - Suggest making the following para from section 1.1 as the second para in section 1.2 - since "iSCSI" hasn't even been defined in its current context. For performance reasons, iSCSI allows a "phase-collapse" (e.g., command and its associated data may be shipped together from initiator to target and data and responses may be shipped together from targets). - Suggest dropping the sentence " The numbering is session-wide." in section 1.2.2.1 since that's repeating the same from six paras earlier. - Suggest substituting the following in 1.2.2.1 Once the device serving part of the target SCSI has received a command, CmdSN ceases to be significant. with Once the iSCSI command PDU is considered eligible for execution either by the device serving part of the target SCSI or the target iSCSI layer itself, CmdSN ceases to be significant. - Suggest dropping the following from 1.2.2.1 since it is describing possibly implementation notes which are covered in section 7.3. Referring to section 7.3 for further discussion would be appropriate. iSCSI may avoid delivering some command to the SCSI layer if so required by some prior SCSI or iSCSI action (e.g., clear task set Task Management request received before all the commands it was supposed to act on). - Suggest moving the following last para from section 1.2.5 Each iSCSI session to a target is treated as if it originated from a different and logically independent initiator. into the second para on 1.2.3, and drop the following text in there. If an initiator and target are connected through more than one session, both the initiator and target perceive the other as a different entity on each session (a different I_T nexus in SAM-2 parlance). - Suggest changing the SHOULD to MAY in the following sentence in 1.2.4 in view of scope for d-o-s attacks. At the target, closing the connection SHOULD be preceded by a Reject PDU sent to the initiator. - Suggest adding the phrase "and when the connection is not in the full-feature phase" at the end to the following sentence in 1.2.6 Graceful connection shutdowns MUST only occur when there are no outstanding tasks that have allegiance to the connection. - Suggest substituting "PDUs" with "opcode types" in the following sentence in 2.2.2.4 - These fields have different meanings for different PDUs. - Suggest additionally qualifying the following in 2.3.4 - If the command is a retry (the X bit is 1) this field will contain.... to If the command is a retry (the X bit is 1) establishing a new connection allegiance, this field will contain.... - Suggest replacing the following sentence fragment in 2.4.8 - For responses sent because of retry the StatSN used MUST be the same... with For responses sent due to retransmission requests, the StatSN used MUST be the same.... since I don't think even replaying (ERT terminology) a command would result in the same StatSN/CmdSN. From owner-ips@ece.cmu.edu Wed Jun 13 23:52:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07435 for ; Wed, 13 Jun 2001 23:52:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5E29nm25263 for ips-outgoing; Wed, 13 Jun 2001 22:09:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5DNHjg14174 for ; Wed, 13 Jun 2001 19:17:45 -0400 (EDT) Received: from phys-ha3mpka.Eng.Sun.COM ([129.146.19.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00421; Wed, 13 Jun 2001 16:17:37 -0700 (PDT) Received: from sonu (sonu [129.146.48.127]) by phys-ha3mpka.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id QAA10024; Wed, 13 Jun 2001 16:17:34 -0700 (PDT) Message-Id: <200106132317.QAA10024@phys-ha3mpka.Eng.Sun.COM> Date: Wed, 13 Jun 2001 16:19:06 -0700 (PDT) From: "Tanjore K. Suresh" Reply-To: "Tanjore K. Suresh" Subject: RE: iSCSI: version 0.6 - Query? To: Tanjore.Suresh@sun.com, ips@ece.cmu.edu, rgriswold@Crossroads.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vc+ga8r3VbNoZ0GP2O2J9g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, > This is a very good question. If "silently ignore" means that at the > time of receipt the target should not attempt to qualify the receipt of > the command at the time it received it, but instead attempt to resolve > this after the MaxCmdSN has been sent, then I would say it makes sense, > but your question interests me with regards to recovery. Since section > 6.1 requires Targets to reject PDUs in a session with format errors > (assuming a misaligned CmdSN constitutes a format error) then it would > seem that this section on page 12 is not in agreement with recovery. I didnot see it explicitly stated in section 6.3 as it is done for DATA sequence number and STATUS sequence number. That is what i am expecting to be corrected in the subsequent revision if everybody aggrees. And also remove the page 12 statement about "siliently Ignoring". Thanks sureshtk > > -----Original Message----- > From: Tanjore K. Suresh [mailto:Tanjore.Suresh@Sun.COM] > Sent: Sunday, June 10, 2001 12:26 AM > To: ips@ece.cmu.edu > Subject: iSCSI version 0.6 - Query? > > Hi, > > Page 12, Last paragraph. > > Regarding the command sequence number. > > " The target MUST silently *ignore* any command outside this range or > duplicates with in the range that have not been flagged with the retry > bit > (the X bit in the opcode)" > > > Why ignore commands which are not in the expected range or duplicates > with in the range? This type of ignoring could cause initator to > cause some unnecessary recovery activity which could/may end up to > be not good for the target which is hale and healthy. > > Such a command could have been errorneously numbered or errorneously > checked for this condition or errnoneously delivered with sequence > number change because of problems transporting it over the internet > fabric. > > Hence, my opinion is appropriate error need to be returned for such > command > instead of ignoring. > > > Comments? > > > Thanks > sureshtk > > > I > > > From owner-ips@ece.cmu.edu Thu Jun 14 08:35:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26544 for ; Thu, 14 Jun 2001 08:35:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5EA21h05030 for ips-outgoing; Thu, 14 Jun 2001 06:02:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com ([32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5E5DQg07199 for ; Thu, 14 Jun 2001 01:13:26 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id BAA316596 for ; Thu, 14 Jun 2001 01:11:34 -0400 Received: from d01hub02.pok.ibm.com (d01hub02.pok.ibm.com [9.117.200.19]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5E57YB90560 for ; Thu, 14 Jun 2001 01:07:34 -0400 Importance: Normal Subject: Re: iSCSI: Login Question Clarifications To: "Kaladhar Voruganti" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Julian Satran" Date: Thu, 14 Jun 2001 08:15:02 +0300 X-MIMETrack: Serialize by Router on D01HUB02/01/H/IBM(Release 5.07a |May 14, 2001) at 06/14/2001 01:13:18 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Kaladhar, 1)There is only 1 Login PDU inititiator to target (the initial) but 1 or 2 responses (if there are 2 the first says go-ahead). All the rest are text exchanges. 2) the last Text (see 1) or Login (if it is the only one) must have the F bit set to 1. 3)CmdSN is advanced but there can be only one command outstanding (in general there can be only one text command outstanding) - that makes text sequences simple. Your case c is not valid. InitSN - not so relevant - there is only one outstanding. Anyhow it should be increased to keep the mechanisms uniform. Section 2.11.5 says: 1.1.1 InitStatSN This is the starting status Sequence Number for this connection. The value is relevant for all subsequent responses. If the login phase involves two login responses (a partial response and a final response) then the InitStatSN in each of them will hold for the subsequent responses. This field is valid only if the Status Class is 0. 4)Enable ACA is dead - we assume the SAM will have a Unit Attention Condition with ACA like behaviour. Kaladhar Voruganti@IBMUS 13-06-2001 21:06 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu From: Kaladhar Voruganti/Almaden/IBM@IBMUS Subject: iSCSI: Login Question Clarifications Hi Julian, I need your help in clarifying the following iSCSI Login questions: 1) When you interleave Login command and Text command messages during the login phase, does the last message from the initiator to the target have to be a Login command message, or can it be also a Text message? 2) The last Login message from the initiator must have the F bit set? 3) During multi-phased login process: a) Does the initiator keep the CmdSn value to be constant (say 1) or does it increase it during each of the login phases (including for the interleaving Text commands)? b) Does the target keep the InitStatSN value to be constant? c) If you have a login command, a text command and then again a login command, then how does the target set the StatSN value and the InitStatSN value? 4) The default value for Max connections is set to 8, and the default value for EnableACA is yes. If the initiator sends a single Login message with the F bit set to 1 (and it does not specifiy these login keys), then this means that the target must support 8 connections per session, and must support ACA. I think that the default values for these two keys should be changed. Are these being changed in Revision 7? Kaladhar From owner-ips@ece.cmu.edu Thu Jun 14 08:35:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26545 for ; Thu, 14 Jun 2001 08:35:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5EA2NE05049 for ips-outgoing; Thu, 14 Jun 2001 06:02:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5E5bgg08649 for ; Thu, 14 Jun 2001 01:37:42 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA16388 for ; Thu, 14 Jun 2001 07:37:36 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5E5baa77664 for ; Thu, 14 Jun 2001 07:37:36 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A6B.001EC479 ; Thu, 14 Jun 2001 07:36:03 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Thu, 14 Jun 2001 08:39:07 +0300 Subject: Re: iSCSI: All text keys MUST be supported? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, You are right> 2.9.3 has also been modified and it reads: 1.1.1 Text Response Data The Text Response Data Segment contains responses in the same key=value format as the Text Command and with the same length and coding constraints. Appendix C lists some basic Text Commands and their Responses. Text response key=value pairs should be delivered in the same order as the command key=value pairs whenever applicable. Although the initiator is the requesting party and controls the request-response initiation and termination the target can offer key=value pairs of its own as part of a sequence and not only in response to an identical key=value pair offered by the initiator. Regards, Julo "Eddy Quicksall" on 14-06-2001 02:30:01 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: All text keys MUST be supported? Looks good, but what about 2.9.3? Should that have the following statement removed? Because you could use that fact to just ignore the key if you don't understand it. If the statement stands, one would have to wonder what the original intent was. 2.9.3 says: If the Text Response does not contain a key that was requested, the initiator must assume that the key was not understood by the target or that the answer is =none. Eddy ----- Original Message ----- From: To: Sent: Wednesday, June 13, 2001 1:32 PM Subject: RE: iSCSI: All text keys MUST be supported? > > > 1.2.4 reads now: > > 1.1.1 Text Mode Negotiation > > During login and thereafter some session or connection parameters are > negotiated through an exchange of textual information. > > In "list" negotiation, the offering party sends a list of values for a > key in its order of preference. > > The responding party answers with the first value from the list it > supports and is allowed to use for the specific initiator. > > The value "none" MUST always be used to indicate a missing function. > However, none is a valid selection only if it is explicitly offered and > MAY be selected by omission (i.e., =none MAY be omitted). > > If a target is not supporting, or not allowed to use with a specific > initiator, any of the offered options, it may use the value "reject". > The values "none" and "reject" are reserved and must be used only as > described here. Any key not understood is answered with > "NotUnderstood". > > The general format of text negotiation is: > > Offer-> =,,..., > Answer-> =|reject|NotUnderstood > > In "numerical" negotiations, the offering and responding party state a > numerical value. The result of the negotiation is key dependent; > frequently the lower or the higher of the two values is used. > > Although the initiator is the requesting party and controls the > request-response initiation and termination the target can offer > key=value pairs of its own as part of a sequence and not only in > response to an identical key=value pair offered by the initiator. > > > And 2.8.3 reads: > > 1.1.1 Text > > The initiator sends the target a set of key=value or key=list pairs > encoded in UTF-8 Unicode. The key and value are separated by a '=' > (0x3D) delimiter. Many key=value pairs can be included in the Text block > by separating them with null (0x00) delimiters. A list is a set of > values separated by comma (0x2C). Large binary items can be encoded > using their hexadecimal representation (e.g., 8190 is 0x1FFE) or decimal > representation. The maximum length of an individual value (not its > string representation) is 255 bytes. > > The data length of a text command or response SHOULD be less than 4096 > bytes. Key names MUST NOT exceed 64 bytes. Key values MUST NOT exceed > 255 characters. > > Character strings are represented as plain text. Numeric and binary > values are represented using either decimal numbers or the hexadecimal > 0x'ffff' notation. The result is adjusted to the specific key. > > The target responds by sending its response back to the initiator. The > response text format is similar to the request text format. > > Some basic key=value pairs are described in Appendix A and D. All of > these keys, except for the X- extension format, MUST be supported by > iSCSI initiators and targets. > > Manufacturers may introduce new keys by prefixing them with X- followed > by their (reversed) domain name, for example the company owning the > domain acme.com can issue: > > X-com.acme.bar.foo.do_something=0000000000000003 > > Any other key not understood by the target may be ignored by the target > without affecting basic function. However the Text Response for a key > that was not understood MUST be key=NotUnderstood. > > Text operations are usually meant for parameter setting/negotiations but > can be used also to perform some active operations. > > It is recommended that Text operations that will take a long time should > be placed in their own Text command. > > A session may have only one outstanding text command at any given time. > > Julo > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" on > 13-06-2001 20:09:18 > > Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" > > > To: "'Eddy Quicksall'" , Julian > Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: RE: iSCSI: All text keys MUST be supported? > > > > > I interpret 2.8.3 to mean "an iSCSI implementation is REQUIRED to recognize > and answer all text keys specified in the iSCSI protocol document. Some > features negotiated with these text commands are OPTIONAL to implement." > > Julian, is that your intention? Would you make the wording more explicit? > > The further text is implicitly refering to 'proprietary' text keys a vendor > may dream up. > > Marj > > > -----Original Message----- > > From: Eddy Quicksall [mailto:EQuicksall@mediaone.net] > > Sent: Tuesday, June 12, 2001 10:20 AM > > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > > Subject: iSCSI: All text keys MUST be supported? > > > > > > > > Section "2.8.3 Text" says: > > > > All of these keys, except for the X- extension format, > > MUST be supported by iSCSI initiators and targets. > > > > But it further says: > > > > Any other key not understood by the target may be ignored without > > affecting basic function. If the Text Response does not > > contain a key > > that was requested, the initiator must assume that the key was not > > understood by the target or, whenever appropriate, that > > the response > > was "none". > > > > These two statements seem contradictory (I don't think the > > 2nd is talking > > about only the X keys). I vote for removing the 1st paragraph above > > and going with the 2nd. That way we would not have to insist > > that every > > key be supported ... the requester would just take the default if the > > receiver did not support the key. > > > > Actually, section "2.9.3 Text Response Data" says: > > > > If the Text Response does not contain a key that > > was requested, the initiator must assume that the key was not > > understood by the target or that the answer is =none. > > > > This seems to backup the 2nd paragraph above. > > > > > > > > Eddy@Quicksall.com > > > > > > From owner-ips@ece.cmu.edu Thu Jun 14 12:45:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03851 for ; Thu, 14 Jun 2001 12:45:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5EEOi021779 for ips-outgoing; Thu, 14 Jun 2001 10:24:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5EEFSg21165 for ; Thu, 14 Jun 2001 10:15:28 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id HAA07424; Thu, 14 Jun 2001 07:14:51 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 07:14:50 -0700 Message-ID: From: Robert Snively To: "Harmon, Robert" , "Ips (E-mail)" Subject: RE: Common Encapsulation: CRC at beginning of frame? Date: Thu, 14 Jun 2001 07:14:44 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I assume you are speaking of the FCIP/iFCP common encapsulation. The data CRC is actually at the end of the encapsulation frame. The header CRC (proposed for use by iFCP only) is at the end of the header. The FCIP usage of the header exploits the combination of TCP/IP protection, data frame verification, and data redundancy to achieve error detection at a comparable level and does not use the header CRC, simplifying the hardware and/or software implementations significantly. Hope that is some help. Bob -----Original Message----- From: Harmon, Robert [mailto:rharmon@entradanet.com] Sent: Wednesday, June 13, 2001 2:20 PM To: Ips (E-mail) Subject: Common Encapsulation: CRC at beginning of frame? Has there been any discussion of putting the common encapsulation CRC at the end of the frame rather than -near- the beginning? Its possible to do CRC in H/W but to put it at the beginning of the frame is 5 times harder than putting it at the end. From owner-ips@ece.cmu.edu Thu Jun 14 20:50:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12200 for ; Thu, 14 Jun 2001 20:50:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5ENEcH01208 for ips-outgoing; Thu, 14 Jun 2001 19:14:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gateway.sanlight.org (adsl-63-202-160-80.dsl.snfc21.pacbell.net [63.202.160.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5ENEag01203 for ; Thu, 14 Jun 2001 19:14:36 -0400 (EDT) Received: from littlejoy (10.0.0.32.lan.sanlight.net [10.0.0.32]) by gateway.sanlight.org (8.11.0/8.11.0) with SMTP id f5F0KF121116; Thu, 14 Jun 2001 17:20:15 -0700 (PDT) (envelope-from dotis@sanlight.net) From: "Douglas Otis" To: "Robert Snively" , "Harmon, Robert" , "Ips \(E-mail\)" Subject: RE: Common Encapsulation: CRC at beginning of frame? Date: Thu, 14 Jun 2001 16:11:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert, In understanding the difference between these two approaches, iFCP could use the header CRC as framing confirmation together with the timestamp in a more resilient manner than FCIP. iFCP also includes the Fibre-Channel frame designators within the header for easier processing. Doug > I assume you are speaking of the FCIP/iFCP common encapsulation. The > data CRC is actually at the end of the encapsulation frame. > The header CRC (proposed for use by iFCP only) is at the end of the > header. The FCIP usage of the header exploits the combination of > TCP/IP protection, data frame verification, and data redundancy > to achieve error detection at a comparable level and does not use > the header CRC, simplifying the hardware and/or software > implementations significantly. > > Hope that is some help. > > Bob > > -----Original Message----- > From: Harmon, Robert [mailto:rharmon@entradanet.com] > Sent: Wednesday, June 13, 2001 2:20 PM > To: Ips (E-mail) > Subject: Common Encapsulation: CRC at beginning of frame? > > > > > Has there been any discussion of putting the > common encapsulation CRC at the end of the frame > rather than -near- the beginning? > Its possible to do CRC in H/W but to put it at the > beginning of the frame is 5 times harder than putting > it at the end. > From owner-ips@ece.cmu.edu Thu Jun 14 20:53:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12242 for ; Thu, 14 Jun 2001 20:53:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5EMMvH27853 for ips-outgoing; Thu, 14 Jun 2001 18:22:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5EMMsg27844 for ; Thu, 14 Jun 2001 18:22:55 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 15:22:46 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE6506CE81@med.corp.rhapsodynetworks.com> From: Dennis Young To: "Ips (E-mail)" Subject: iSCSI autosense and ACA Date: Thu, 14 Jun 2001 15:22:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, I would appreciate if someone could clarify why ACA is needed if autosense is mandatory? Thanks, Dennis --- Section 3.3.3 and 7.2 of rev 06 are copied here for reference: 3.3 iSCSI Port Mode Page The following outlines the iSCSI Port mode page: ... 3.3.2 Enable ACA (A) When this field is set to 1 the target is mandated to enter ACA state as specified. When set to 0 the target shall not enter ACA state. This field can also be set by a text-mode key=value pair (EnableACA). 7.2 Autosense and Auto Contingent Allegiance (ACA) Autosense refers to the automatic return of sense data to the initiator in case a command did not complete successfully. iSCSI mandates support for autosense. ACA helps preserve ordered command execution in presence of errors. As iSCSI can have many commands in-flight between initiator and target iSCSI mandates support for ACA. From owner-ips@ece.cmu.edu Thu Jun 14 22:48:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15145 for ; Thu, 14 Jun 2001 22:48:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5F00pe04164 for ips-outgoing; Thu, 14 Jun 2001 20:00:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com (imail.corp.iready.com [209.140.229.69]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5F00ng04160 for ; Thu, 14 Jun 2001 20:00:49 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 17:00:43 -0700 Message-ID: <034670D62D19D31180990090277A37B701895F2F@mercury.corp.iready.com> From: Satya Vardharajan To: ips@ece.cmu.edu Subject: iSCSI Performance metrics? Date: Thu, 14 Jun 2001 17:00:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F52E.32EB0E20" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F52E.32EB0E20 Content-Type: text/plain; charset="iso-8859-1" Hello All, Does anyone have any data to share regarding iSCSI performance metrics ? What are the metrics used to measure performance? What is considered as acceptable performance? I have in mind the following 2 scenarios 1. iSCSI implementation on the Host at 1 Gbps 2. iSCSI offloaded on to a processor at 1 Gbps Any information would be appreciated. Thanks, Satya ------_=_NextPart_001_01C0F52E.32EB0E20 Content-Type: text/html; charset="iso-8859-1" iSCSI Performance metrics?

Hello All,
 Does anyone have any data to share regarding iSCSI performance metrics ?
 What are the metrics used to measure performance? What is considered as acceptable performance?
 I have in mind the following 2 scenarios
 1. iSCSI implementation on the Host at 1 Gbps 
 2. iSCSI offloaded on to a processor  at 1 Gbps

Any information would be appreciated.

Thanks,
Satya

 

------_=_NextPart_001_01C0F52E.32EB0E20-- From owner-ips@ece.cmu.edu Thu Jun 14 22:51:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15163 for ; Thu, 14 Jun 2001 22:51:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5F0tTp07424 for ips-outgoing; Thu, 14 Jun 2001 20:55:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5ENKRg01602 for ; Thu, 14 Jun 2001 19:20:27 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA23736; Thu, 14 Jun 2001 16:20:16 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 16:20:15 -0700 Message-ID: From: Robert Snively To: "'Douglas Otis'" , "Ips (E-mail)" Subject: RE: Common Encapsulation: CRC at beginning of frame? Date: Thu, 14 Jun 2001 16:20:11 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Your "easier" and "more resilient" statements are implementation dependent. Our work indicates that both of those are incorrect statements for at least one very efficient implementation. Bob > -----Original Message----- > From: Douglas Otis [mailto:dotis@sanlight.net] > Sent: Thursday, June 14, 2001 4:12 PM > To: Robert Snively; Harmon, Robert; Ips (E-mail) > Subject: RE: Common Encapsulation: CRC at beginning of frame? > > > Robert, > > In understanding the difference between these two > approaches, iFCP could use > the header CRC as framing confirmation together with the > timestamp in a more > resilient manner than FCIP. iFCP also includes the > Fibre-Channel frame > designators within the header for easier processing. > > Doug > > > I assume you are speaking of the FCIP/iFCP common > encapsulation. The > > data CRC is actually at the end of the encapsulation frame. > > The header CRC (proposed for use by iFCP only) is at the end of the > > header. The FCIP usage of the header exploits the combination of > > TCP/IP protection, data frame verification, and data redundancy > > to achieve error detection at a comparable level and does not use > > the header CRC, simplifying the hardware and/or software > > implementations significantly. > > > > Hope that is some help. > > > > Bob > > > > -----Original Message----- > > From: Harmon, Robert [mailto:rharmon@entradanet.com] > > Sent: Wednesday, June 13, 2001 2:20 PM > > To: Ips (E-mail) > > Subject: Common Encapsulation: CRC at beginning of frame? > > > > > > > > > > Has there been any discussion of putting the > > common encapsulation CRC at the end of the frame > > rather than -near- the beginning? > > Its possible to do CRC in H/W but to put it at the > > beginning of the frame is 5 times harder than putting > > it at the end. > > > > From owner-ips@ece.cmu.edu Thu Jun 14 23:26:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15385 for ; Thu, 14 Jun 2001 23:26:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5F0tAv07358 for ips-outgoing; Thu, 14 Jun 2001 20:55:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5EM1dg26360 for ; Thu, 14 Jun 2001 18:01:39 -0400 (EDT) Received: from phys-ha3mpka.Eng.Sun.COM ([129.146.44.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22523; Thu, 14 Jun 2001 15:01:36 -0700 (PDT) Received: from sonu (sonu [129.146.48.127]) by phys-ha3mpka.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id PAA01189; Thu, 14 Jun 2001 15:01:36 -0700 (PDT) Message-Id: <200106142201.PAA01189@phys-ha3mpka.Eng.Sun.COM> Date: Thu, 14 Jun 2001 15:03:07 -0700 (PDT) From: "Tanjore K. Suresh" Reply-To: "Tanjore K. Suresh" Subject: Re: iSCSI:Text field in Asynchronous Message To: ips@ece.cmu.edu, kaladhar@us.ibm.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vfHAlZqyh/tGJe2diPwjiw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ips@ece.cmu.edu Precedence: bulk Kaladhar, > Will there ever be a need for a Target to send an asynchronous Text message > to the initiators (for potential performance optimizations)? So far in my opinion/understanding, the Initiator part is considered to be the master and target responds to it to complete the master's request. But now you want the otherway in some conditions, i am wondering what those conditions are so that we can make a call. > > According to the current iSCSI specification, the initiators can send Text > messages to the target. > Moreover, the initiators can send vendor specific X- key/values to the > target. > > Now, why can't the targets also have the ability to send X-key/value pairs > to the initiators via Asynch messages? > I would like input from people as to whether this feature will be useful. Assuming that you get this mechanism so that target can send the X-Key/value pair. If any action need to be taken on such X-Key/value pair that means Initiator should have known about the X-Key or such a vendor specific X-key should better be a well advertised one between the initiator implementation and target implementation. So, in my opinion, if the Intiator/Target knows about such a vendor unique X-Key, then why can't the Initiator implementation itself start negotiation for it with the assumption that the target knows about it, if it not known anyway it could be rejected based on the current specification definition of "none" and "reject" values. I am not able to get the point where it will be very much usefull. Please help me if am mistaken. Thanks sureshtk From owner-ips@ece.cmu.edu Fri Jun 15 12:22:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13713 for ; Fri, 15 Jun 2001 12:22:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5FDLnA02439 for ips-outgoing; Fri, 15 Jun 2001 09:21:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5FDLlg02435 for ; Fri, 15 Jun 2001 09:21:48 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5FDLUE11874 for ; Fri, 15 Jun 2001 09:21:30 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 15 Jun 2001 09:21:24 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M6JJGYSA; Fri, 15 Jun 2001 09:21:25 -0400 Received: from travos.nortelnetworks.com (dhcp223-133.engeast.baynetworks.com [192.32.223.133]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JPBDMK03; Fri, 15 Jun 2001 09:21:26 -0400 Message-Id: <5.0.2.1.2.20010615092305.02b76780@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 15 Jun 2001 09:33:23 -0400 To: Robert Snively , "'Douglas Otis'" , "Ips (E-mail)" From: "Franco Travostino" Subject: RE: Common Encapsulation: CRC at beginning of frame? In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3663165==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_3663165==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Gee, how many qualitative, subjective, and implementation-specific statements in this thread! Fore one, Bob's notion of "simplifying", "very efficient", and (implicitly) superior resiliency still fail to convince me, until I read the outcome of the action item that Bob took from the Nashua meeting, and which I hope will be addressed in formal terms: >Section 8.1 - Bob Snbively wants to add ability to do data-based resync >-> Action: Bob will write the text to explain how to do this for serious >review. Will also rewrite the text to distinguish use of another >framing mechanism vs. the data scan. Resync should be optional, and >data scan must not be capable of misinterpreting what appears to >be a Fibre Channel frame in an FCIP data payload as an actual frame. -franco At 07:20 PM 6/14/2001, Robert Snively wrote: >Your "easier" and "more resilient" statements are implementation >dependent. Our work indicates that both of those are incorrect >statements for at least one very efficient implementation. > >Bob > > > -----Original Message----- > > From: Douglas Otis [mailto:dotis@sanlight.net] > > Sent: Thursday, June 14, 2001 4:12 PM > > To: Robert Snively; Harmon, Robert; Ips (E-mail) > > Subject: RE: Common Encapsulation: CRC at beginning of frame? > > > > > > Robert, > > > > In understanding the difference between these two > > approaches, iFCP could use > > the header CRC as framing confirmation together with the > > timestamp in a more > > resilient manner than FCIP. iFCP also includes the > > Fibre-Channel frame > > designators within the header for easier processing. > > > > Doug > > > > > I assume you are speaking of the FCIP/iFCP common > > encapsulation. The > > > data CRC is actually at the end of the encapsulation frame. > > > The header CRC (proposed for use by iFCP only) is at the end of the > > > header. The FCIP usage of the header exploits the combination of > > > TCP/IP protection, data frame verification, and data redundancy > > > to achieve error detection at a comparable level and does not use > > > the header CRC, simplifying the hardware and/or software > > > implementations significantly. > > > > > > Hope that is some help. > > > > > > Bob > > > > > > -----Original Message----- > > > From: Harmon, Robert [mailto:rharmon@entradanet.com] > > > Sent: Wednesday, June 13, 2001 2:20 PM > > > To: Ips (E-mail) > > > Subject: Common Encapsulation: CRC at beginning of frame? > > > > > > > > > > > > > > > Has there been any discussion of putting the > > > common encapsulation CRC at the end of the frame > > > rather than -near- the beginning? > > > Its possible to do CRC in H/W but to put it at the > > > beginning of the frame is 5 times harder than putting > > > it at the end. > > > > > > > --=====================_3663165==_.ALT Content-Type: text/html; charset="us-ascii"
Gee, how many qualitative, subjective, and implementation-specific statements in this thread!
Fore one, Bob's notion of "simplifying", "very efficient", and (implicitly) superior resiliency still fail to convince me, until I read the outcome of the action item that Bob took from the Nashua meeting, and which I hope will be addressed in formal terms:

Section 8.1 - Bob Snbively wants to add ability to do data-based resync
-> Action: Bob will write the text to explain how to do this for serious
review. Will also rewrite the text to distinguish use of another
framing mechanism vs. the data scan. Resync should be optional, and
data scan must not be capable of misinterpreting what appears to
be a Fibre Channel frame in an FCIP data payload as an actual frame.

-franco


At 07:20 PM 6/14/2001, Robert Snively wrote:
Your "easier" and "more resilient" statements are implementation
dependent.  Our work indicates that both of those are incorrect
statements for at least one very efficient implementation.

Bob

>  -----Original Message-----
>  From: Douglas Otis [mailto:dotis@sanlight.net]
>  Sent: Thursday, June 14, 2001 4:12 PM
>  To: Robert Snively; Harmon, Robert; Ips (E-mail)
>  Subject: RE: Common Encapsulation: CRC at beginning of frame?
> 
> 
>  Robert,
> 
>  In understanding the difference between these two
>  approaches, iFCP could use
>  the header CRC as framing confirmation together with the
>  timestamp in a more
>  resilient manner than FCIP.  iFCP also includes the
>  Fibre-Channel frame
>  designators within the header for easier processing.
> 
>  Doug
> 
>  > I assume you are speaking of the FCIP/iFCP common
>  encapsulation.  The
>  > data CRC is actually at the end of the encapsulation frame.
>  > The header CRC (proposed for use by iFCP only) is at the end of the
>  > header.  The FCIP usage of the header exploits the combination of
>  > TCP/IP protection, data frame verification, and data redundancy
>  > to achieve error detection at a comparable level and does not use
>  > the header CRC, simplifying the hardware and/or software
>  > implementations significantly.
>  >
>  > Hope that is some help.
>  >
>  > Bob
>  >
>  > -----Original Message-----
>  > From: Harmon, Robert [mailto:rharmon@entradanet.com]
>  > Sent: Wednesday, June 13, 2001 2:20 PM
>  > To: Ips (E-mail)
>  > Subject: Common Encapsulation: CRC at beginning of frame?
>  >
>  >
>  >
>  >
>  > Has there been any discussion of putting the
>  > common encapsulation CRC at the end of the frame
>  > rather than -near- the beginning?
>  > Its possible to do CRC in H/W but to put it at the
>  > beginning of the frame is 5 times harder than putting
>  > it at the end.
>  >
> 
> 
--=====================_3663165==_.ALT-- From owner-ips@ece.cmu.edu Fri Jun 15 15:32:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25246 for ; Fri, 15 Jun 2001 15:32:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5FHBXV20201 for ips-outgoing; Fri, 15 Jun 2001 13:11:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5FBxKg26919 for ; Fri, 15 Jun 2001 07:59:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04297; Fri, 15 Jun 2001 07:58:47 -0400 (EDT) Message-Id: <200106151158.HAA04297@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-reqmts-04.txt Date: Fri, 15 Jun 2001 07:58:47 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Requirements and Design Considerations Author(s) : M. Krueger et al. Filename : draft-ietf-ips-iscsi-reqmts-04.txt Pages : 24 Date : 14-Jun-01 The IP Storage Working group is chartered with developing comprehensive technology to transport block storage data over IP protocols. This effort includes a protocol to transport the Small Computer Systems Interface (SCSI) protocol over the Internet (iSCSI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-reqmts-04.txt 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-reqmts-04.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-reqmts-04.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: <20010614112307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-reqmts-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-reqmts-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010614112307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Jun 15 22:05:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03743 for ; Fri, 15 Jun 2001 22:05:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5G02Ru20866 for ips-outgoing; Fri, 15 Jun 2001 20:02:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5G02Qg20862 for ; Fri, 15 Jun 2001 20:02:26 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 20:02:20 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A07080156A7@corpmx9.isus.emc.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: London meeting logistics Date: Fri, 15 Jun 2001 20:02:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk I've had several requests for information on the August meetings of the IPS WG in London. This will be during the IETF meeting week, August 6-10. The meeting will be limited to iSCSI and related topics. Fibre Channel-related topics, including FCIP and iFCP will be taken up in a separate interim meeting (possibly later in August) because the London IETF meeting week conflicts with the T11 meeting week. Five hours (two 2.5 hour sessions) of meeting time has been requested on the assumption that we can almost certainly use it, but we may end up with less due to not being able to take up the Fibre Channel portion of our work and the expected heavy demand for meeting time. At this point, no meeting schedule for London is available, and when one appears - please DO NOT take it seriously!! Draft schedules for IETF meetings are remarkably fluid documents - meeting times and dates can and do change as late as two weeks prior to the meeting week, as I've learned the hard way ;-). The overall structure of the London IETF week should be similar to Minneapolis (http://www.ietf.org/meetings/agenda_50.html) - orientation talks and reception on Sunday, WG meetings all day Monday-Thursday, plus Monday evening and Friday morning. Tuesday and Wednesday evenings are set aside for the social event and plenary sessions. Of course, the dates/times of the various WG meetings in London will be completely different from those in Minneapolis. One important difference from T10 and T11 meetings is that there's a separate registration fee - $450 in advance, $600 onsite. One fee covers as many WG meetings as one wants to go to. Since that fee pays for the meeting space, the hotel room block(s) are provided as a courtesy - unlike T10 and T11, there's no ethical duty to stay in a room block associated with the IETF meeting in order to help pay for the meeting space. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Jun 15 23:14:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05202 for ; Fri, 15 Jun 2001 23:14:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5G1LN825492 for ips-outgoing; Fri, 15 Jun 2001 21:21:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5FKNWg06231 for ; Fri, 15 Jun 2001 16:23:32 -0400 (EDT) Received: from eddylaptop (h00e098880aa4.ne.mediaone.net [66.31.75.244]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f5FKNV813352 for ; Fri, 15 Jun 2001 16:23:31 -0400 (EDT) From: "Eddy Quicksall" To: Subject: iSCSI: security and authentication = none Date: Fri, 15 Jun 2001 15:54:27 -0400 Message-ID: <006d01c0f5d9$0d9dfd20$0100a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 4 says: Authentication and a Secure Channel setup MAY be performed independent of iSCSI (as when using tunneling IPSec or some implementations of transport IPSec) in which case the Login phase can be reduced to operational parameter negotiations. Also, if an initiator sends the target HeaderDigest=none DataDigest=none AuthMethod=none, then the target does not have to SecurityContextComplete=Yes (because one of the examples says so). So does that also mean, in this example, that other operational parameters can be sent along with these 3 "none" parameters? I know that section 4 may imply "yes" but since, in my example, the initiator sends the keys maybe the answer is "no". Eddy From owner-ips@ece.cmu.edu Fri Jun 15 23:42:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05707 for ; Fri, 15 Jun 2001 23:42:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5G1scb27420 for ips-outgoing; Fri, 15 Jun 2001 21:54:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [128.221.10.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5G1scg27416 for ; Fri, 15 Jun 2001 21:54:38 -0400 (EDT) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 21:54:32 -0400 Message-ID: <0F31E5C394DAD311B60C00E029101A07080156AA@corpmx9.isus.emc.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: draft-ietf-ips-iscsi-reqmts-04.txt - Informal Last Call Date: Fri, 15 Jun 2001 21:54:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Comments arising from the previous Informal Last Call of the iSCSI requirements draft have been addressed in the latest version, draft-ietf-ips-iscsi-reqmts-04.txt It is intended to submit this draft to the IESG for publication as an Informational RFC. This message announces an informal 2 week WG Last Call for this draft, mostly to check that the changes correctly address the issues with the previous version. This Last Call will end on June 29th. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Jun 15 23:43:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05726 for ; Fri, 15 Jun 2001 23:43:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5G2PLu29332 for ips-outgoing; Fri, 15 Jun 2001 22:25:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from OPUS.PDL.CMU.EDU (root@OPUS.PDL.CMU.EDU [128.2.134.91]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5G2PIg29320 for ; Fri, 15 Jun 2001 22:25:18 -0400 (EDT) Received: from opus.pdl.cmu.edu (bassoon@localhost [127.0.0.1]) by OPUS.PDL.CMU.EDU (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id WAA29158 for ; Fri, 15 Jun 2001 22:25:17 -0400 Message-Id: <200106160225.WAA29158@OPUS.PDL.CMU.EDU> To: ips@ece.cmu.edu subject: iSCSI Design Requirements Date: Fri, 15 Jun 2001 22:25:17 -0400 From: Dave Nagle Sender: owner-ips@ece.cmu.edu Precedence: bulk Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5FBxKg26919 for ; Fri, 15 Jun 2001 07:59:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04297; Fri, 15 Jun 2001 07:58:47 -0400 (EDT) Message-Id: <200106151158.HAA04297@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-reqmts-04.txt Date: Fri, 15 Jun 2001 07:58:47 -0400 Sender: nsyracus@cnri.reston.va.us --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 Requirements and Design Considerations Author(s) : M. Krueger et al. Filename : draft-ietf-ips-iscsi-reqmts-04.txt Pages : 24 Date : 14-Jun-01 The IP Storage Working group is chartered with developing comprehensive technology to transport block storage data over IP protocols. This effort includes a protocol to transport the Small Computer Systems Interface (SCSI) protocol over the Internet (iSCSI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-reqmts-04.txt 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-reqmts-04.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-reqmts-04.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: <20010614112307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-reqmts-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-reqmts-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010614112307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Jun 15 23:46:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05806 for ; Fri, 15 Jun 2001 23:46:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5G2NbY29223 for ips-outgoing; Fri, 15 Jun 2001 22:23:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5FBxKg26919 for ; Fri, 15 Jun 2001 07:59:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04297; Fri, 15 Jun 2001 07:58:47 -0400 (EDT) Message-Id: <200106151158.HAA04297@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-reqmts-04.txt Date: Fri, 15 Jun 2001 07:58:47 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Requirements and Design Considerations Author(s) : M. Krueger et al. Filename : draft-ietf-ips-iscsi-reqmts-04.txt Pages : 24 Date : 14-Jun-01 The IP Storage Working group is chartered with developing comprehensive technology to transport block storage data over IP protocols. This effort includes a protocol to transport the Small Computer Systems Interface (SCSI) protocol over the Internet (iSCSI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-reqmts-04.txt 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-reqmts-04.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-reqmts-04.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: <20010614112307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-reqmts-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-reqmts-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010614112307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Sun Jun 17 11:19:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10901 for ; Sun, 17 Jun 2001 11:19:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5HDhoq18666 for ips-outgoing; Sun, 17 Jun 2001 09:43:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5H6kWg16002 for ; Sun, 17 Jun 2001 02:46:32 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id IAA74460 for ; Sun, 17 Jun 2001 08:46:25 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5H6kPe79854 for ; Sun, 17 Jun 2001 08:46:25 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A6E.00250D98 ; Sun, 17 Jun 2001 08:44:43 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sun, 17 Jun 2001 09:47:58 +0300 Subject: RE: Unsolicited Data. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk The F-flag is used to signal the end-of-unsolicited (+- somew unclarity removed in 07). Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" on 07-06-2001 10:39:59 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu cc: Subject: RE: Unsolicited Data. Hi Stephen, Sanjeev, and other interested parties, I whole heartily agree with both of your comments and see the benefit of unsolicited data in removing the R2T induced latency for both small writes and large writes on systems where such latency is an issue. However, for large writes the unsolicited portion of the data need not be all the data in the transfer but enough to overcome the initial latency. My main concern is that although the initiator and target have negoiated to use unsolicited data (InitialR2t=no), in the spec it appears to be optional. Therefore how does the target know that unsolicited data will be sent. Currently it does not and the target will have to set a timer that expires if no unsolicited data is forthcoming which will incur an even more unacceptable latency. I see that there are two options: 1)State in the spec that if unsolicited data has been negotiated then the initiator MUST honour it. (My preferred) 2)Have a flag in the SCSI Command PDU indicating that data is expected (No thanks). Thanks Matthew Burbridge NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Stephen Bailey [mailto:steph@cs.uchicago.edu] Sent: Thursday, June 07, 2001 2:20 AM To: ips@ece.cmu.edu Subject: Re: Unsolicited Data. Sanjeev, > why would initiator choose not to send unsolicited immediate data when > it has negotiated for IntialR2T= Yes?? I assume you mean InitialR2T=no. I would do this because I think that the real benefit of unsolicited data is for writes where ALL the write data can be sent unsolicited, and I'm happy to have the target schedule the transfer of (ALL) data for larger writes. Of course, others would say I'm a moron. Assuming the overwhelming majority of storage use is file access, small writes are exclusively file system metadata writes. Unsolicited data is a huge win for metadata writes because the latency of these metadata writes is frequently not covered by transferring other data (within a single access thread). On the other hand, the file system (usually) generates enough concurrent demand for real data writes that the flow control (R2T) latency is well hidden. You might argue that if you're running a file system optimized fors today's SANs over a link with a HUGE bandwidth * delay product (greater than the expected demand created by the file system), sending large amounts of unsolicited write data will substantially improve the link utilization. That is true, but I don't think many targets are going to offer unsolicited data bursts remotely that large. In a hardware accelerate implementation, unsolicited data will be handled differently than solicited data. The target can chose where the solicited data is delivered, but unsolicited data arrives through a general-delivery path. Therefore, if the offered unsolicited data burst size approaches the regular burst size, an implementation will need TWICE as much buffer memory (half in the general-delivery area and half in the flow-controlled buffer area) to support the same operation load. Maybe this tradeoff is OK, but given the cost sensitivity of storage targets, I doubt it. As always, I welcome comments from those who see things differently. Steph From owner-ips@ece.cmu.edu Sun Jun 17 11:19:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10903 for ; Sun, 17 Jun 2001 11:19:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5HDhjg18652 for ips-outgoing; Sun, 17 Jun 2001 09:43:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5H6cTg15543 for ; Sun, 17 Jun 2001 02:38:29 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA277874 for ; Sun, 17 Jun 2001 08:38:23 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5H6cNe52446 for ; Sun, 17 Jun 2001 08:38:23 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A6E.002452D1 ; Sun, 17 Jun 2001 08:36:44 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sun, 17 Jun 2001 09:39:58 +0300 Subject: Re: addendum Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk 07 will have a change log (in general terms not page-after-page). Julo "Eddy Quicksall" on 07-06-2001 00:29:48 Please respond to eddy_quicksall@ivivity.com To: ips@ece.cmu.edu cc: Subject: addendum Is there an addendum or a list of EMAIL's that describe the changes going into REV 7? If not, what do you think about creating one. It could go on the http://www.ece.cmu.edu/~ips/Docs/docs.html page. mailto:Eddy@Quicksall.com From owner-ips@ece.cmu.edu Sun Jun 17 11:22:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10929 for ; Sun, 17 Jun 2001 11:22:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5HDhru18672 for ips-outgoing; Sun, 17 Jun 2001 09:43:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5HB26g09918 for ; Sun, 17 Jun 2001 07:02:06 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id NAA266634 for ; Sun, 17 Jun 2001 13:02:00 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5HB20e99258 for ; Sun, 17 Jun 2001 13:02:00 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A6E.003C7456 ; Sun, 17 Jun 2001 13:00:19 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sun, 17 Jun 2001 14:03:38 +0300 Subject: Re: DataSegmentLength of 0 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Barry, OK - it reads: 1.1.1 DataSegmentLength This is the data payload length of a SCSI Data-In or SCSI Data-Out PDU; sending of 0 length data segments should be avoided, but initiators and targets must be able to properly receive 0 length data segments. Regards, Julo "Barry Reinhold" on 07-06-2001 17:06:19 Please respond to "Barry Reinhold" To: Julian Satran/Haifa/IBM@IBMIL cc: "Jon Sreekanth" , "James Smart" Subject: DataSegmentLength of 0 Julian, Clause 2.7.6, DataSegmentLength, States the following: "This is the data payload length of a SCSI Data-In or SCSI Data-Out PDU; sending of 0 length data segments should be avoided." For devices that are going to act as protocol translators between Fibre Channel and iSCSI it is going to be just about impossible not to send a data segment length of 0 if we get an underrun condition. (This happens on inquery responses. From the Fibre Channel side there is no way to tell that the data has been sent until you get a FCP_RSP. At this point the iSCSI data frames have already been sent with all the data, but the F bit still needs to be set. The translating device therefore needs to send a frame with a 0 length data segment and the F bit set.) Hence, I suspect almost all devices that are not acting as end points to IO operations will have this problem and you will see iSCSI data frames with the F bit set and the 0 length data segments. I agree that we don't want to send 0 length segments, but I do think we need to be able to handle them if they are generated. In order to make people aware of the need to handle 0 length frames I was looking for wording changes to the spec along these lines: "This is the data payload length of a SCSI Data-In or SCSI Data_Out PDU; sending of 0 length data segments should be avoided, but devices must be able to properly receive 0 length data segments." In this way it makes it clear that reception of 0 length data segments is required (which I think was the intent) and devices will be more likely to interoperate. Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Sun Jun 17 11:23:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10940 for ; Sun, 17 Jun 2001 11:23:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5HDhuX18679 for ips-outgoing; Sun, 17 Jun 2001 09:43:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5HCWEg14688 for ; Sun, 17 Jun 2001 08:32:14 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id OAA318840; Sun, 17 Jun 2001 14:31:27 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5HCVIe79688; Sun, 17 Jun 2001 14:31:18 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A6E.00449EF0 ; Sun, 17 Jun 2001 14:29:31 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: Stephen Bailey , cbm@rose.hp.com cc: ips@ece.cmu.edu Message-ID: Date: Sun, 17 Jun 2001 15:18:38 +0300 Subject: Re: iSCSI ERT: handling for iSCSI response codes Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Steph, That is an interesting change in opinion. When I suggested the same thing some releases ago for the same set of reasons (I even suggested avoiding the response codes at all!) as there is no noticeable difference in handling the heat of your response was felt at 6000 miles. However I am not sure anymore that given the need for a clearing action for most of those cases that we should not keep the treatment within the iSCSI layer and create an iSCSI-exception-condition (for all iSCSI created responses) cleared through an iSCSI task management function (clear-iSCSI-exception) and reject all intervening commands. This type of handling will let us build independent of SCSI and keep the layering purists happy. Regards, Julo Stephen Bailey on 14-06-2001 05:42:09 Please respond to Stephen Bailey To: cbm@rose.hp.com cc: Julian Satran/Haifa/IBM@IBMIL, someshg@yahoo.com, venkat@rhapsodynetworks.com, ldalleore@snapserver.com, Black_David@emc.com, John Hufferd/San Jose/IBM@IBMUS, kalman_meth@il.ibm.com Subject: Re: iSCSI ERT: handling for iSCSI response codes Mallikarjun, > Comments? Hmm. Ok, I agree. For example, I never really thought: > 0x02 - Delivery Subsystem Failure was the right way to report in-band integrity errors. Delivery subsystem failure usually means something that is not even detectable by the target, like a timeout. As such, I agree that the target shouldn't be responding this back. Yes, I have seen many FCP targets do exactly what you're suggesting here. In fact 0xB 0x4700 (good ole SCSI parity error) is code for many different protocol errors which are detectable and attributable to a particular SCSI command. For example, bogus settings of FCP F_CTL bits. So, assuming that Target Failure, Delivery Subsystem Failure are all attributable to a SCSI command, I agree they should create CHECK conditions. The place where response values are justified is if the error is attributable to something other than a SCSI command, such as a task management function. For example, task management function rejected (which we don't seem to have). If we were anticipating any of these as a response to task management, they should remain, or perhaps we should define new, more specifically task management related responses codes. I'm not clear on what you're proposing for SNACK rejected, but, since it's not CHECK CONDITION, I'm sure whatever you have in mind is fine, but we need to document it better :^) Steph From owner-ips@ece.cmu.edu Sun Jun 17 11:24:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10955 for ; Sun, 17 Jun 2001 11:24:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5HDhdK18638 for ips-outgoing; Sun, 17 Jun 2001 09:43:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5H5K7g11345 for ; Sun, 17 Jun 2001 01:20:07 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA274300 for ; Sun, 17 Jun 2001 07:20:00 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5H5Jte91590 for ; Sun, 17 Jun 2001 07:20:00 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A6E.001D23ED ; Sun, 17 Jun 2001 07:18:17 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sun, 17 Jun 2001 08:21:27 +0300 Subject: Re: Unsolicited Data. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk It may vary from command to command. A simple cdesign may decide to send immediate data only when it will contain all it has to send and send in separate PDUs if it has more (solicited or unsolicited). I saw no real reason to enforce a behavior or other. Julo "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" on 07-06-2001 02:05:39 Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" To: ips@ece.cmu.edu cc: Subject: Re: Unsolicited Data. Hello, All that is said below is ok but I cannot understand one thing here ----- why would initiator choose not to send unsolicited immediate data when it has negotiated for IntialR2T= Yes?? Sanjeev ----- Original Message ----- From: "Ayman Ghanem" To: Sent: Wednesday, June 06, 2001 6:48 PM Subject: RE: Unsolicited Data. > That section was modified. Julian posted the revised text here: > > http://ips.pdl.cs.cmu.edu/mail/msg04647.html > > -Ayman > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Sent: Wednesday, June 06, 2001 9:36 AM > > To: 'ips@ece.cmu.edu' > > Subject: RE: Unsolicited Data. > > > > > > > > The current spec states that the F bit is "set to 1 when the > > immediate data > > that accompany the command are all the data associated with this > > command. It > > is an error if the Length and Expected Length do not match and this bit is > > set to 1". > > > > I interpret this as there is no more data to follow and not that the > > initiator has opted not to use the unsolicited data feature. > > Therefore the > > spec needs to be modified to indicate that if unsolicited data has been > > negotiated (i.e. InitialR2T=no), then the initiator MUST send unsolicited > > data of length = min( FirstBurstSize, ExpectedTransferLength ) minus any > > immediate data sent). > > > > Matthew Burbridge > > NIS-Bristol > > Hewlett Packard > > Telnet: 312 7010 > > E-mail: matthewb@bri.hp.com > > > > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Tuesday, June 05, 2001 6:31 PM > > To: ips@ece.cmu.edu > > Subject: RE: Unsolicited Data. > > > > > > If the initiator decides not to send immediate or unsolicited data when it > > has negotiated to do so, then the initiator must set the F-bit in the > > command PDU. This prompts the target to send R2T. > > > > I still agree that the spec should indicate that the initiator > > MUST use the > > resources it has negotiated. If it has negotiated the option to send > > immediate data or unsolicited data then it should do that to the limits > > allowed. If it has negotiated a PDU length, it must not send data > > PDUs less > > than the negotiated limit except for last one. While most > > implementation may > > do that for performance reasons, I would prefer defining this in the spec. > > > > -Ayman > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > Sent: Tuesday, June 05, 2001 11:58 AM > > > To: 'ips@ece.cmu.edu' > > > Subject: Unsolicited Data. > > > > > > > > > I'm not sure if this has been discussed before but it is causing some > > > confusion. The statement below implies that if immediate data has been > > > negotiated then the initiator MAY use it. > > > > > > "If ImmediateData is set to no and InitialR2T is set to no then the > > > initiator MUST NOT send unsolicited immediate data but MAY send one > > > unsolicited burst of Data-OUT PDUs." > > > > > > Therefore the target must wait for the initial burst of unsolicited data > > > before issuing the first R2T (if there is subsequent data). If the > > > initiator decides not to send it then the target must timeout and > > > issue the > > > R2T for the initial data. Can the spec be changed to state that if > > > unsolicited data has been negotiated, then the initiator MUST use it. > > > > > > Thanks > > > > > > Matthew Burbridge > > > NIS-Bristol > > > Hewlett Packard > > > Telnet: 312 7010 > > > E-mail: matthewb@bri.hp.com > > > > > > > > > From owner-ips@ece.cmu.edu Sun Jun 17 11:24:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10966 for ; Sun, 17 Jun 2001 11:24:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5HDhgs18645 for ips-outgoing; Sun, 17 Jun 2001 09:43:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5H6bqg15492 for ; Sun, 17 Jun 2001 02:37:52 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA277864 for ; Sun, 17 Jun 2001 08:37:46 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5H6bke114710 for ; Sun, 17 Jun 2001 08:37:46 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A6E.00244203 ; Sun, 17 Jun 2001 08:36:01 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sun, 17 Jun 2001 09:37:58 +0300 Subject: Re: iSCSI: More draft-06 comments Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk This has been done. Julo Steve Senum on 07-06-2001 01:58:27 Please respond to Steve Senum To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: More draft-06 comments Matt Wakeley wrote: > > julian_satran@il.ibm.com wrote: > > > ++++ although this text has no ambiguity there is still a raging debate > > between the proponents of an always explicit response (Matt and - in some > > covoluted form Steph - and those like Steve Senum who whould like a hiatus > > signaling a default. The current text let you set none by default. This > > can be changed by removing the " and MAY be selected by omission... " +++ > > I would like the "and MAY be selected by omission..." removed. If the "NotUnderstood" response exists, I would also like to see the option of not sending a response of key:none removed. Steve Senum From owner-ips@ece.cmu.edu Sun Jun 17 13:17:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11244 for ; Sun, 17 Jun 2001 13:17:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5HFSAv24570 for ips-outgoing; Sun, 17 Jun 2001 11:28:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5HFS9g24566 for ; Sun, 17 Jun 2001 11:28:09 -0400 (EDT) Received: from cs.uchicago.edu (h005018030f43.ne.mediaone.net [24.91.86.255]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f5HFRd613315; Sun, 17 Jun 2001 11:27:40 -0400 (EDT) Message-Id: <200106171527.f5HFRd613315@chmls20.mediaone.net> To: julian_satran@il.ibm.com cc: cbm@rose.hp.com, ips@ece.cmu.edu Subject: Re: iSCSI ERT: handling for iSCSI response codes In-Reply-To: Message from julian_satran@il.ibm.com of "Sun, 17 Jun 2001 15:18:38 +0300." References: Date: Sun, 17 Jun 2001 11:27:35 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, > That is an interesting change in opinion. If it is, I am sorry. I was mistaken. However, I thought there was a difference between what I was arguing against then and what we are discussing here. Whatever the case, it's irrelevant. Here's what I think now, and I apologize for either my misunderstanding, failure to communicate effectively, or my sheer idiocy, if this contradicts any previous statements. What I am opposed to is the initiator synthesizing SCSI status. On a irrecoverable initiator-detected failure during an identified task, the initiator should report an appropriate service response code, and not a CHECK CONDITION. However, on the target side, the target should report every error for which it is possible to do so, with an appropriate SCSI status code (e.g. CHECK CONDITION). Response codes (or an analogous mechanism) are STILL the right thing for errors which can not be reported with SCSI status, such as task management errors. When I say analogous mechanism, either the iSCSI Reject or Task Management response (or both) could convey the equivalent information. I could well imagine arguing that target responses should be signalled analogously (equivalently) to FCP (SRP etc.), which means a single response PDU covers all cases (command response and task management response). The role of the response code is clear in that case. Once upon a time I held out hope for that, but clearly we're far from there now, so I won't continue to argue for it. Presently, I agree that the response field in the SCSI Response PDU seems superfluous. It's only 5435 miles from Lawrence to Haifa. We're not as far apart on this as you suggest :^) Steph From owner-ips@ece.cmu.edu Sun Jun 17 13:52:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11431 for ; Sun, 17 Jun 2001 13:52:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5HGLdL27590 for ips-outgoing; Sun, 17 Jun 2001 12:21:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe32.law11.hotmail.com [64.4.16.89]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5HGLbg27586 for ; Sun, 17 Jun 2001 12:21:37 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 17 Jun 2001 09:21:31 -0700 X-Originating-IP: [66.31.75.244] From: "Eddy Quicksall" To: , References: Subject: Re: DataSegmentLength of 0 Date: Sun, 17 Jun 2001 12:21:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 17 Jun 2001 16:21:31.0882 (UTC) FILETIME=[91E60CA0:01C0F749] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Then why say "avoided"? Saying "avoided" simply adds to confusion because one does not know why you said it. An explanation would be in order if it really should be avoided under some circumstances. I would prefer that the "avoided" part is removed. Eddy ----- Original Message ----- From: To: Sent: Sunday, June 17, 2001 7:03 AM Subject: Re: DataSegmentLength of 0 > > > Barry, > > OK - it reads: > > 1.1.1 DataSegmentLength > > This is the data payload length of a SCSI Data-In or SCSI Data-Out PDU; > sending of 0 length data segments should be avoided, but initiators and > targets must be able to properly receive 0 length data segments. > > > Regards, > Julo > > "Barry Reinhold" on 07-06-2001 17:06:19 > > Please respond to "Barry Reinhold" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: "Jon Sreekanth" , "James Smart" > > Subject: DataSegmentLength of 0 > > > > > Julian, > Clause 2.7.6, DataSegmentLength, > > States the following: > > "This is the data payload length of a SCSI Data-In or SCSI Data-Out > PDU; sending of 0 length data segments should be avoided." > > For devices that are going to act as protocol translators between Fibre > Channel and iSCSI it is going to be just about impossible not to send a > data > segment length of 0 if we get an underrun condition. (This happens on > inquery responses. From the Fibre Channel side there is no way to tell that > the data has been sent until you get a FCP_RSP. At this point the iSCSI > data > frames have already been sent with all the data, but the F bit still needs > to be set. The translating device therefore needs to send a frame with a 0 > length data segment and the F bit set.) Hence, I suspect almost all > devices > that are not acting as end points to IO operations will have this problem > and you will see iSCSI data frames with the F bit set and the 0 length data > segments. I agree that we don't want to send 0 length segments, but I do > think we need to be able to handle them if they are generated. > > In order to make people aware of the need to handle 0 length frames I was > looking for wording changes to the spec along these lines: > > "This is the data payload length of a SCSI Data-In or SCSI Data_Out > PDU; > sending of 0 length data segments should be avoided, but devices must be > able to properly receive 0 length data segments." > > In this way it makes it clear that reception of 0 length data segments is > required (which I think was the intent) and devices will be more likely to > interoperate. > Barry Reinhold > Principal Architect > Trebia Networks > barry.reinhold@trebia.com > 603-868-5144/603-659-0885/978-929-0830 x138 > > > > > From owner-ips@ece.cmu.edu Mon Jun 18 03:21:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01614 for ; Mon, 18 Jun 2001 03:21:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5I5Oca14937 for ips-outgoing; Mon, 18 Jun 2001 01:24:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5I5Obg14932 for ; Mon, 18 Jun 2001 01:24:37 -0400 (EDT) Received: from ahganemw2k (sj-dial-4-79.cisco.com [171.68.181.208]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id BAA06096 for ; Mon, 18 Jun 2001 01:24:29 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iSCSI: MaxCmdSN Date: Mon, 18 Jun 2001 00:23:25 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, The text in section 2.4.10 should make it clear that a response PDU from the target with MaxCmdSN=ExpCmdSN-1 is permitted, to handle the case when the target's window has reached 0. It is OK for the initiator to ignore the MaxCmdSN but not the ExpCmdSN. Also, if the initiator has no other commands pending at the target, the target MUST send a NOP-IN advancing the MaxCmdSN to update the corresponding value at the initiator. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Ayman Ghanem > Sent: Monday, June 11, 2001 2:11 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: MaxCmdSN > > > Nick, > > Yes, it will be an error for MaxCmdSN to have a value < (ExpCmdSN > - 1), and > I agree that MaxCmdSN = (ExpCmdSN - 1) should be permitted. As for the > target receiving a PDU with CmdSN > MaxCmdSN, it is stated in > draft-06 (near > the end of 1.2.2.1) that the target MUST silently ignore such a > command. No > reject PDU needs to be sent. > > -Ayman > > > > -----Original Message----- > > From: Martin, Nick [mailto:Nick.Martin@compaq.com] > > Sent: Monday, June 11, 2001 12:00 PM > > To: 'Ayman Ghanem'; ips@ece.cmu.edu > > Subject: RE: iSCSI: MaxCmdSN > > > > > > Ayman, > > > > I thought I understood this, and I had a great explanation > supporting the > > draft (06), but I now realize I was "off by one". I believe you > > are correct > > that ExpCmdSN will be one greater than MaxCmdSN if-and-only-if an > > acknowledgement is to be sent while the window is closed. > > > > The purpose of ExpCmdSN and MaxCmdSN transmitted by the target, is to > > advance values with the same names maintained in the initiator. > ExpCmdSN > > acknowledges receipt of all CmdSN values < ExpCmdSN. MaxCmdSN is the > > largest CmdSN the target promises to accept, and conversely the largest > > CmdSN the initiator is permitted to send. > > > > The target can not regress these numbers in the initiator. When > > the target > > transmits (and the initiator accepts) N as the MaxCmdSN, the > initiator is > > allowed to transmit CmdSN values through N. Then it must stop. > > Any number > > of additional PDUs may carry the same MaxCmdSN value. None of > these will > > cause the initiator's value to advance. A response carrying a > > MaxCmdSN less > > than the initiator's current MaxCmdSN value is presumed to have arrived > > late. It does not advance nor regress the initiator's present value. > > > > After the initiator sends CmdSN of MaxCmdSN (still N), it can > not send any > > more until MaxCmdSN advances. It should be permitted for the target to > > acknowledge the receipt of all commands received through this > > CmdSN which is > > N. In this case ExpCmdSN would be N + 1 and MaxCmdSN is still > N. We know > > that no commands are in flight. When the target is able to > accept another > > command, it must advance MaxCmdSN (value > N in serial > arithmetic), and it > > will send the new value to the initiator in the next inbound PDU (i.e. > > data-in, SCSI response, or nop-in). > > > > Yes, I believe it would be a protocol error for MaxCmdSN to have a value > > less than ExpCmdSN - 1. This would be an acknowledgement for a > > CmdSN which > > the initiator was not yet permitted to send. I think MaxCmdSN equal to > > ExpCmdSN - 1 should be permitted. > > > > Note however that nothing will break if this acknowledgement is not > > immediately sent or, having been sent, does not advance the initiator's > > values. The window is already closed and remains so. While > the window is > > closed, the initiator will be holding the last PDU sent as > unacknowledged, > > when the target has in fact received it. The PDU will be successfully > > acknowledged when MaxCmdSN advances, because ExpCmdSN in the > > target will not > > advance simultaneously while the window is closed. > > > > Was this done intentionally to delay the last acknowledgement when the > > window is closed, or is it an "off by one" issue in draft 06? > > > > This made me think about a related issue: > > It think it would be permitted for the target to reject or drop > a PDU with > > CmdSN greater than MaxCmdSN, but I am not sure if it is > required to do so. > > I do not see a response code the target could send that would tell the > > initiator what it did wrong. > > > > Thanks, > > Nick > > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Monday, June 11, 2001 9:18 AM > > To: ips@ece.cmu.edu > > Subject: iSCSI: MaxCmdSN > > > > > > In section 2.4.10, "if the PDU MaxCmdSN is less than the PDU > > ExpCmdSN ...., > > they are both ignored". Is this considered an invalid response from the > > target?. What happens when the target queuing capacity reaches 0. For > > example: target received and processed cmdsn N, but can not > receive cmdsn > > N+1 yet. In the response for N, target puts N+1 for > > expectedCmdSN. How does > > it inform the initiator that its window is closed?. Setting > MaxCmdSN to N > > will be ignored if I understand the above paragraph correctly. > > > > -Ayman > > > > > > From owner-ips@ece.cmu.edu Mon Jun 18 15:01:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16910 for ; Mon, 18 Jun 2001 15:01:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5IGZfv07849 for ips-outgoing; Mon, 18 Jun 2001 12:35:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [192.151.10.58]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5IGZQg07840 for ; Mon, 18 Jun 2001 12:35:26 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 37B3E1F58C for ; Mon, 18 Jun 2001 09:35:20 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id JAA00177 for ips@ece.cmu.edu; Mon, 18 Jun 2001 09:36:30 -0700 (PDT) Message-Id: <200106181636.JAA00177@core.rose.hp.com> Subject: (Start of) iSCSI ERT: handling for iSCSI response codes To: ips@ece.cmu.edu Date: Mon, 18 Jun 2001 9:36:30 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Let me post the complete context for that email exchange, since I was the one proposing this change in ERT. Please take time to read these short messages, I would appreciate comments. One line quote from my message behind this proposal: "To summarize, IMHO, iSCSI is presumptively signaling the task conclusion with its response codes." Responding to Julian: >This type of handling will let us build independent of SCSI .... Julian, the fact is that we can not completely be "independent of SCSI" except we start building in redundant mechanisms like ACA at iSCSI level. I thought we were dropping the EnableACA "feature" precisely because we did not want to build in this redundancy! Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com -------------------------------------------------------------------------- Date: Thu, 07 Jun 2001 19:37:10 PDT To: cbm@rose.hp.com Subject: iSCSI ERT: handling for iSCSI response codes Cc: julian_satran@il.ibm.com, someshg@yahoo.com, venkat@rhapsodynetworks.com, steph@cs.uchicago.edu, ldalleore@snapserver.com, Black_David@emc.com, hufferd@us.ibm.com, kalman_meth@il.ibm.com In-Reply-To: <200106060116.SAA00914@core.rose.hp.com>; from "Mallikarjun C." at Jun 5, 101 6:16 pm Status: RO Team, After exchanging some messages with Ralph Weber and Ed Gardner, I am coming to the conclusion that all the error cases which result in "iSCSI response codes" in the SCSI Response PDU should in fact result in SCSI CHECK CONDITION - to result in ACA if NACA=1 was set for the failing command, ie. to kick in the regular SCSI processing. Following are defined in draft rev06 - 0x01 - Target Failure 0x02 - Delivery Subsystem Failure 0x03 - Unsolicited data rejected 0x04 - SNACK rejected Note that commands failing with any of these response codes would cause out-of-order execution for the follow-on commands - even with NACA=1, simply because iSCSI can not mandate ACA, a SCSI-ism, to enforce ordering (we dropped EnableACA kludge because of this reason). The solution I see is to instead have iSCSI mandate a standard SCSI CHECK CONDITION on these errors with the current response codes acting as detailed descriptions. It turns out there are already reasonable ASC/ASCQ values defined for these cases (for all SCSI device types) in SPC-2. Here they are - ASC ASCQ Means Target Failure -> 0x44 0x00 Internal Target Failure Delivery Subsystem -> 0x47 0x03 Information Unit CRC error Failure detected SNACK rejected -> -do - -do- (since the root cause is the same) Unsolicited data -> 0x49 0x00 Invalid Message Error rejected To summarize, I propose that iSCSI mandate CHECK CONDITION with the ASC/ASCQ values as shown above - instead of limiting to iSCSI response codes. This cleanly takes care of the ACA issue. There are precedents in SCSI Protocol standards like FCP-2 for mandating such behavior. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com ------------------------------------------------------------------------- Date: Thu, 14 Jun 2001 10:58:04 PDT To: steph@cs.uchicago.edu Subject: Re: iSCSI ERT: handling for iSCSI response codes Cc: cbm@rose.hp.com, julian_satran@il.ibm.com, someshg@yahoo.com, venkat@rhapsodynetworks.com, ldalleore@snapserver.com, Black_David@emc.com, hufferd@us.ibm.com, kalman_meth@il.ibm.com In-Reply-To: <200106140242.f5E2g9603398@chmls20.mediaone.net>; from "Stephen Bailey" at Jun 13, 101 7:43 pm Status: RO Steph, Thanks for the message. >I'm not clear on what you're proposing for SNACK rejected, but, since >it's not CHECK CONDITION, I'm sure whatever you have in mind is fine, >but we need to document it better :^) Sorry, I was using proprietary (and confidential) shorthand, :-) Actually, I was proposing a CHECK CONDITION (0x47, 0x03) even for "SNACK rejected" since the "root cause is the same" - ie. a prior data integrity error! Keep in mind that employing SNACK means the task is already considered in progress by both parties - the target iSCSI is fabricating a SCSI Response PDU without its SCSI involvement, it's technically incorrect since the task is already instantiated at its SCSI layer. That's what the source of the problem here is. To summarize, IMHO, iSCSI is presumptively signaling the task conclusion with its response codes. The correct options are a) iSCSI should not deliver a SCSI Response at all, forcing a timeout and thus the standard SCSI recovery. OR b) iSCSI should mandate a CHECK CONDITION - which technically involves task cleanup at target SCSI layer, and leads to the right ordering semantics. My suggestion was ofcourse (b), for faster error recovery. I haven't seen a response from Julian yet, hope he's accommodating this in rev07! Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com > >Mallikarjun, > >> Comments? > >Hmm. Ok, I agree. > >For example, I never really thought: > >> 0x02 - Delivery Subsystem Failure > >was the right way to report in-band integrity errors. Delivery >subsystem failure usually means something that is not even detectable >by the target, like a timeout. As such, I agree that the target >shouldn't be responding this back. > >Yes, I have seen many FCP targets do exactly what you're suggesting >here. In fact 0xB 0x4700 (good ole SCSI parity error) is code for >many different protocol errors which are detectable and attributable >to a particular SCSI command. For example, bogus settings of FCP >F_CTL bits. > >So, assuming that Target Failure, Delivery Subsystem Failure are all >attributable to a SCSI command, I agree they should create CHECK >conditions. > >The place where response values are justified is if the error is >attributable to something other than a SCSI command, such as a task >management function. For example, task management function rejected >(which we don't seem to have). If we were anticipating any of these >as a response to task management, they should remain, or perhaps we >should define new, more specifically task management related responses >codes. > >I'm not clear on what you're proposing for SNACK rejected, but, since >it's not CHECK CONDITION, I'm sure whatever you have in mind is fine, >but we need to document it better :^) > >Steph > ------------------------------------------------------------------------------ >Steph, > >That is an interesting change in opinion. When I suggested the same thing >some releases ago for the same set of reasons >(I even suggested avoiding the response codes at all!) as there is no >noticeable difference in handling the heat of your response was felt at >6000 miles. > >However I am not sure anymore that given the need for a clearing action for >most of those cases that we should not keep >the treatment within the iSCSI layer and create an >iSCSI-exception-condition (for all iSCSI created responses) cleared through >an iSCSI task management function (clear-iSCSI-exception) and reject all >intervening commands. > >This type of handling will let us build independent of SCSI and keep the >layering purists happy. > >Regards, >Julo > From owner-ips@ece.cmu.edu Mon Jun 18 15:03:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16965 for ; Mon, 18 Jun 2001 15:03:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5IHkOa13374 for ips-outgoing; Mon, 18 Jun 2001 13:46:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5IHaKg12565 for ; Mon, 18 Jun 2001 13:36:20 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id TAA186112 for ; Mon, 18 Jun 2001 19:36:10 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5IHa9K29604 for ; Mon, 18 Jun 2001 19:36:09 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A6F.00608A36 ; Mon, 18 Jun 2001 19:34:28 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Mon, 18 Jun 2001 20:42:01 +0300 Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, I was asked by many of you what codes to use for the plugfest. I think you would want to consider using the already published codes for 07 (published on this list) as an alternative to 06. The transition to 07 will be easier and you will have far less interoperability issues. Regards, Julo ---------------------- Forwarded by Julian Satran/Haifa/IBM on 18-06-2001 20:38 --------------------------- "Lynn, Bill" on 23-05-2001 19:37:42 Please respond to bill_lynn@btc.adaptec.com To: "'snia-ipsforum@snia.org'" cc: Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation IP Storage Forum Member The IP Storage Forum is pleased to announce the first IP Storage Forum plugfest to be held on the 17th and 18th of July at the University of New Hampshire's InterOperability Lab. This event is open to all IP Storage Forum members and there will be a nominal fee of $250.00 per engineer attending. The current plan is to test to the iSCSI draft standards versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a call for participation please respond with your company's intent to participate. Information we would like to know is: Company Name Contact Name (email and phone number) Number of engineers attending Number and types of products to be tested Protocol type and version implemented Logistical information should follow within the next two weeks. The goal of the plugfest is to do some low level protocol testing along with some higher level system testing. The information on types of products will determine the possible configurations we can construct. Please email the above information to - bill_lynn@corp.adaptec.com If there are any questions please feel free to contact me at 303-684-4706. Thanks Bill Lynn Secretary SNIA IP Storage Forum #### att1.htm has been deleted (was saved in repository My Attachments Repository ->(Document link: Link to the attachment in the repository)) from this note on 11 June 2001 by Julian Satran From owner-ips@ece.cmu.edu Mon Jun 18 16:33:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20354 for ; Mon, 18 Jun 2001 16:33:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5IJCu220275 for ips-outgoing; Mon, 18 Jun 2001 15:12:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5IJCsg20268 for ; Mon, 18 Jun 2001 15:12:55 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 15:12:49 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0708F9@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion Date: Mon, 18 Jun 2001 15:10:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Since this topic has surfaced on this list, it is my understanding that this plugfest is now open to all participants, not just SNIA or UNH iSCSI consortium members. FYI and thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com] > Sent: Monday, June 18, 2001 1:42 PM > To: ips@ece.cmu.edu > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for > Participation > > > > Dear colleagues, > > I was asked by many of you what codes to use for the plugfest. I think you > would want to consider using the already published codes for 07 (published > on this list) as an alternative to 06. The transition to 07 will be > easier > and you will > have far less interoperability issues. > > Regards, > Julo > ---------------------- Forwarded by Julian Satran/Haifa/IBM on 18-06-2001 > 20:38 --------------------------- > > "Lynn, Bill" on 23-05-2001 19:37:42 > > Please respond to bill_lynn@btc.adaptec.com > > To: "'snia-ipsforum@snia.org'" > cc: > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation > > > > > IP Storage Forum Member > > The IP Storage Forum is pleased to announce the first IP Storage Forum > plugfest to be held on the 17th and 18th of July at the University of New > Hampshire's InterOperability Lab. This event is open to all IP Storage > Forum members and there will be a nominal fee of $250.00 per engineer > attending. The current plan is to test to the iSCSI draft standards > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a > call > for participation please respond with your company's intent to > participate. > Information we would like to know is: > > Company Name > Contact Name (email and phone > number) > Number of engineers attending > Number and types of products to be > tested > Protocol type and version > implemented > > Logistical information should follow within the next two weeks. The goal > of > the plugfest is to do some low level protocol testing along with some > higher > level system testing. The information on types of products will determine > the possible configurations we can construct. Please email the above > information to - > > > bill_lynn@corp.adaptec.com > > If there are any questions please feel free to contact me at 303-684-4706. > > > Thanks > > > Bill Lynn > > Secretary > > SNIA IP Storage Forum > > > > #### att1.htm has been deleted (was saved in repository My Attachments > Repository ->(Document link: Link to the attachment in the repository)) > from this note on 11 June 2001 by Julian Satran > > From owner-ips@ece.cmu.edu Mon Jun 18 16:34:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20370 for ; Mon, 18 Jun 2001 16:34:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5IImcm18446 for ips-outgoing; Mon, 18 Jun 2001 14:48:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h014.c007.snv.cp.net [209.228.33.221]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5IImbg18441 for ; Mon, 18 Jun 2001 14:48:37 -0400 (EDT) Received: (cpmta 23826 invoked from network); 18 Jun 2001 11:48:30 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.221) with SMTP; 18 Jun 2001 11:48:30 -0700 X-Sent: 18 Jun 2001 18:48:30 GMT From: "Douglas Otis" To: , Subject: RE: iSCSI: Wrapping up SendTargets Date: Mon, 18 Jun 2001 11:46:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit LJ, Rather than mandating a non-existent standard (one modified to implement signaling), there is already a method of signaling using ICMP for other types of networking protocols. If this signaling is of a critical nature, then adopting two ICMP codes for SAN Notice and Reply together with a means of logging running servers could provide an alternative. This would only entail registry of these codes. Finding a means to log running servers could be done with protocols like LDAP, SLP or equivalents. With the assumption that there will be agents running (servers perhaps) that notice events that needs propagated, a list of servers would enable that function. It would then be incumbent upon the transport to further that signal to the clients to minimize this change to only those devices providing a SAN related service. The signal would be an indication to recheck configurations. Doug > Modified SLP should be the mandatory to implement. > > SendTargets is allowed under a grandfather agreement since it is > out there and should be carried in an Annex with a clear notation > that it is obsolete and is there because of pre-standard implementations. > > There is no need to mention iSNS - that is pretty nearly a vendor > specific approach to solving their perception of a problem, open > source available or not. > > > > > At 06/12/2001, Jim Hafner wrote: > > Folks, > > I think this thread is wandering off the field. > > The question is the issue of SendTargets. Let's remind ourselves of the > original purpose of this proposed protocol: namely, it's designed for a > storage box that contains one or more iSCSI target devices to report about > ITSELF, about what's in it! This includes both a list of the > iSCSI targets > it has PLUS the session coordination (via tags) of the various > IPaddress/tcpport combos it supports. > > In other words, it's job is to report about itself! The use of (unicast) > SLP as an alternative to SendTargets was focused exactly on the same > question: I ask a single box to tell me about itself. This function lies > between the two extremes of (a) static configuration of initiators and (b) > centralized management via iSNS style services. > > Somehow, someway, we need to define a protocol for a box to "tell us about > itself" in the absense of the centralized management infrastructure. That > seems critical to me. Even if I want to do static configuration, the guy > doing the configuration needs a way to get at the guts of each new box > he/she rolls into the environment. > > The choices are, it seems, that *every* box would need to support at least > one of: > a) SendTargets > b) modified SLP > c) iSNS > > What's the consensus on the protocol we aim for to solve this > middle ground > discovery problem? > Jim Hafner > > From owner-ips@ece.cmu.edu Mon Jun 18 16:35:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20426 for ; Mon, 18 Jun 2001 16:35:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5IJRCc21424 for ips-outgoing; Mon, 18 Jun 2001 15:27:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5IJRAg21419 for ; Mon, 18 Jun 2001 15:27:10 -0400 (EDT) Received: (cpmta 26381 invoked from network); 18 Jun 2001 12:27:04 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.220) with SMTP; 18 Jun 2001 12:27:04 -0700 X-Sent: 18 Jun 2001 19:27:04 GMT From: "Douglas Otis" To: , Subject: RE: iSCSI: ICMP for Notification? Date: Mon, 18 Jun 2001 12:24:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0708F8@corpmx14.us.dg.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, I did not intend this to be related directly to iSCSI, but instead to a class of protocols. I indicated this signal could be 'SAN' related allowing it to be used for any SAN class of transport. It would not be modifying ICMP but rather adding to the signal types. My goal was to avoid doing anything iSCSI specific and, in addition, I was attempting to further limit use to just those devices providing services. If you view this a critical signal related to networking changes, then ICMP does seem like the proper protocol for this level of notification. It would provide only a notice of change. It would allow any number of SAN related protocols the ability to then query services like SLP, LADP etc. Rather than changing every possible management related service, this one method could provide a means of keeping management models and the many related protocols unaffected and unchanged. Doug Doug > > With my WG co-chair hat on, I want to discourage > Doug's proposed use of ICMP as a bad idea - I > can't imagine this ever making it to the IESG, > let alone being approved by them. Even the > experimental SLP notification would be a far > better approach. Please do not spend any further > list bandwidth on modifying ICMP specifically for > iSCSI. > > Thanks, > --David > > > -----Original Message----- > > From: Douglas Otis [SMTP:dotis@sanlight.net] > > Sent: Monday, June 18, 2001 2:46 PM > > To: ljlamers@mindspring.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: Wrapping up SendTargets > > > > LJ, > > > > Rather than mandating a non-existent standard (one modified to implement > > signaling), there is already a method of signaling using ICMP for other > > types of networking protocols. If this signaling is of a > critical nature, > > then adopting two ICMP codes for SAN Notice and Reply together with a > > means > > of logging running servers could provide an alternative. This would only > > entail registry of these codes. Finding a means to log running servers > > could be done with protocols like LDAP, SLP or equivalents. With the > > assumption that there will be agents running (servers perhaps) > that notice > > events that needs propagated, a list of servers would enable that > > function. > > It would then be incumbent upon the transport to further that signal to > > the > > clients to minimize this change to only those devices providing a SAN > > related service. The signal would be an indication to recheck > > configurations. > > > > > > Doug > > > > > Modified SLP should be the mandatory to implement. > > > > > > SendTargets is allowed under a grandfather agreement since it is > > > out there and should be carried in an Annex with a clear notation > > > that it is obsolete and is there because of pre-standard > > implementations. > > > > > > There is no need to mention iSNS - that is pretty nearly a vendor > > > specific approach to solving their perception of a problem, open > > > source available or not. > > > > > > > > > > > > > > > At 06/12/2001, Jim Hafner wrote: > > > > > > Folks, > > > > > > I think this thread is wandering off the field. > > > > > > The question is the issue of SendTargets. Let's remind > ourselves of the > > > original purpose of this proposed protocol: namely, it's > designed for a > > > storage box that contains one or more iSCSI target devices to report > > about > > > ITSELF, about what's in it! This includes both a list of the > > > iSCSI targets > > > it has PLUS the session coordination (via tags) of the various > > > IPaddress/tcpport combos it supports. > > > > > > In other words, it's job is to report about itself! The use of > > (unicast) > > > SLP as an alternative to SendTargets was focused exactly on the same > > > question: I ask a single box to tell me about itself. This function > > lies > > > between the two extremes of (a) static configuration of initiators and > > (b) > > > centralized management via iSNS style services. > > > > > > Somehow, someway, we need to define a protocol for a box to "tell us > > about > > > itself" in the absense of the centralized management infrastructure. > > That > > > seems critical to me. Even if I want to do static configuration, the > > guy > > > doing the configuration needs a way to get at the guts of each new box > > > he/she rolls into the environment. > > > > > > The choices are, it seems, that *every* box would need to support at > > least > > > one of: > > > a) SendTargets > > > b) modified SLP > > > c) iSNS > > > > > > What's the consensus on the protocol we aim for to solve this > > > middle ground > > > discovery problem? > > > Jim Hafner > > > > > > > From owner-ips@ece.cmu.edu Mon Jun 18 16:35:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20437 for ; Mon, 18 Jun 2001 16:35:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5IJBdL20175 for ips-outgoing; Mon, 18 Jun 2001 15:11:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5IJBcg20170 for ; Mon, 18 Jun 2001 15:11:38 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 15:13:21 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0708F8@corpmx14.us.dg.com> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Subject: iSCSI: ICMP for Notification? Date: Mon, 18 Jun 2001 15:08:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk With my WG co-chair hat on, I want to discourage Doug's proposed use of ICMP as a bad idea - I can't imagine this ever making it to the IESG, let alone being approved by them. Even the experimental SLP notification would be a far better approach. Please do not spend any further list bandwidth on modifying ICMP specifically for iSCSI. Thanks, --David > -----Original Message----- > From: Douglas Otis [SMTP:dotis@sanlight.net] > Sent: Monday, June 18, 2001 2:46 PM > To: ljlamers@mindspring.com; ips@ece.cmu.edu > Subject: RE: iSCSI: Wrapping up SendTargets > > LJ, > > Rather than mandating a non-existent standard (one modified to implement > signaling), there is already a method of signaling using ICMP for other > types of networking protocols. If this signaling is of a critical nature, > then adopting two ICMP codes for SAN Notice and Reply together with a > means > of logging running servers could provide an alternative. This would only > entail registry of these codes. Finding a means to log running servers > could be done with protocols like LDAP, SLP or equivalents. With the > assumption that there will be agents running (servers perhaps) that notice > events that needs propagated, a list of servers would enable that > function. > It would then be incumbent upon the transport to further that signal to > the > clients to minimize this change to only those devices providing a SAN > related service. The signal would be an indication to recheck > configurations. > > > Doug > > > Modified SLP should be the mandatory to implement. > > > > SendTargets is allowed under a grandfather agreement since it is > > out there and should be carried in an Annex with a clear notation > > that it is obsolete and is there because of pre-standard > implementations. > > > > There is no need to mention iSNS - that is pretty nearly a vendor > > specific approach to solving their perception of a problem, open > > source available or not. > > > > > > > > > > At 06/12/2001, Jim Hafner wrote: > > > > Folks, > > > > I think this thread is wandering off the field. > > > > The question is the issue of SendTargets. Let's remind ourselves of the > > original purpose of this proposed protocol: namely, it's designed for a > > storage box that contains one or more iSCSI target devices to report > about > > ITSELF, about what's in it! This includes both a list of the > > iSCSI targets > > it has PLUS the session coordination (via tags) of the various > > IPaddress/tcpport combos it supports. > > > > In other words, it's job is to report about itself! The use of > (unicast) > > SLP as an alternative to SendTargets was focused exactly on the same > > question: I ask a single box to tell me about itself. This function > lies > > between the two extremes of (a) static configuration of initiators and > (b) > > centralized management via iSNS style services. > > > > Somehow, someway, we need to define a protocol for a box to "tell us > about > > itself" in the absense of the centralized management infrastructure. > That > > seems critical to me. Even if I want to do static configuration, the > guy > > doing the configuration needs a way to get at the guts of each new box > > he/she rolls into the environment. > > > > The choices are, it seems, that *every* box would need to support at > least > > one of: > > a) SendTargets > > b) modified SLP > > c) iSNS > > > > What's the consensus on the protocol we aim for to solve this > > middle ground > > discovery problem? > > Jim Hafner > > > > From owner-ips@ece.cmu.edu Mon Jun 18 17:30:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21640 for ; Mon, 18 Jun 2001 17:29:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5IJs4F23554 for ips-outgoing; Mon, 18 Jun 2001 15:54:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5IJs2g23550 for ; Mon, 18 Jun 2001 15:54:02 -0400 (EDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id TAA29014; Mon, 18 Jun 2001 19:53:58 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 18 Jun 2001 19:53:58 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 12:53:56 -0700 Message-ID: <9678C2B4D848D41187450090276D1FAE0AEFDADD@FMSMSX32> From: "Zamer, Ahmad" To: "'Black_David@emc.com'" , "'ips@ece.cmu.edu'" Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion Date: Mon, 18 Jun 2001 12:53:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi David, Just a clarification. The invitation sent out by Bill Lynn states that "This event is open to all IP Storage > Forum members and there will be a nominal fee of $250.00 per engineer > attending. The current plan is to test to the iSCSI draft standards > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a > call > for participation please respond with your company's intent to > participate." Although opening the event to all may be a good idea, the invitation did not go that far. Regards, Ahmad Zamer Intel Corporation voice: 512-407-2155 mail: ahmad.zamer@intel.com -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Monday, June 18, 2001 2:10 PM To: ips@ece.cmu.edu Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion Since this topic has surfaced on this list, it is my understanding that this plugfest is now open to all participants, not just SNIA or UNH iSCSI consortium members. FYI and thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com] > Sent: Monday, June 18, 2001 1:42 PM > To: ips@ece.cmu.edu > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for > Participation > > > > Dear colleagues, > > I was asked by many of you what codes to use for the plugfest. I think you > would want to consider using the already published codes for 07 (published > on this list) as an alternative to 06. The transition to 07 will be > easier > and you will > have far less interoperability issues. > > Regards, > Julo > ---------------------- Forwarded by Julian Satran/Haifa/IBM on 18-06-2001 > 20:38 --------------------------- > > "Lynn, Bill" on 23-05-2001 19:37:42 > > Please respond to bill_lynn@btc.adaptec.com > > To: "'snia-ipsforum@snia.org'" > cc: > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation > > > > > IP Storage Forum Member > > The IP Storage Forum is pleased to announce the first IP Storage Forum > plugfest to be held on the 17th and 18th of July at the University of New > Hampshire's InterOperability Lab. This event is open to all IP Storage > Forum members and there will be a nominal fee of $250.00 per engineer > attending. The current plan is to test to the iSCSI draft standards > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a > call > for participation please respond with your company's intent to > participate. > Information we would like to know is: > > Company Name > Contact Name (email and phone > number) > Number of engineers attending > Number and types of products to be > tested > Protocol type and version > implemented > > Logistical information should follow within the next two weeks. The goal > of > the plugfest is to do some low level protocol testing along with some > higher > level system testing. The information on types of products will determine > the possible configurations we can construct. Please email the above > information to - > > > bill_lynn@corp.adaptec.com > > If there are any questions please feel free to contact me at 303-684-4706. > > > Thanks > > > Bill Lynn > > Secretary > > SNIA IP Storage Forum > > > > #### att1.htm has been deleted (was saved in repository My Attachments > Repository ->(Document link: Link to the attachment in the repository)) > from this note on 11 June 2001 by Julian Satran > > From owner-ips@ece.cmu.edu Mon Jun 18 19:23:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23856 for ; Mon, 18 Jun 2001 19:23:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5ILWBF01106 for ips-outgoing; Mon, 18 Jun 2001 17:32:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe24.law11.hotmail.com [64.4.16.81]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5ILW9g01098 for ; Mon, 18 Jun 2001 17:32:09 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Jun 2001 14:32:03 -0700 X-Originating-IP: [216.135.246.226] From: "Eddy Quicksall" To: References: Subject: Re: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation Date: Mon, 18 Jun 2001 17:32:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 18 Jun 2001 21:32:03.0537 (UTC) FILETIME=[1DA4BC10:01C0F83E] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Can someone give us a pointer to the new op/codes? Eddy ----- Original Message ----- From: To: Sent: Monday, June 18, 2001 1:42 PM Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation > > > Dear colleagues, > > I was asked by many of you what codes to use for the plugfest. I think you > would want to consider using the already published codes for 07 (published > on this list) as an alternative to 06. The transition to 07 will be easier > and you will > have far less interoperability issues. > > Regards, > Julo > ---------------------- Forwarded by Julian Satran/Haifa/IBM on 18-06-2001 > 20:38 --------------------------- > > "Lynn, Bill" on 23-05-2001 19:37:42 > > Please respond to bill_lynn@btc.adaptec.com > > To: "'snia-ipsforum@snia.org'" > cc: > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation > > > > > IP Storage Forum Member > > The IP Storage Forum is pleased to announce the first IP Storage Forum > plugfest to be held on the 17th and 18th of July at the University of New > Hampshire's InterOperability Lab. This event is open to all IP Storage > Forum members and there will be a nominal fee of $250.00 per engineer > attending. The current plan is to test to the iSCSI draft standards > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a > call > for participation please respond with your company's intent to participate. > Information we would like to know is: > > Company Name > Contact Name (email and phone > number) > Number of engineers attending > Number and types of products to be > tested > Protocol type and version > implemented > > Logistical information should follow within the next two weeks. The goal > of > the plugfest is to do some low level protocol testing along with some > higher > level system testing. The information on types of products will determine > the possible configurations we can construct. Please email the above > information to - > > > bill_lynn@corp.adaptec.com > > If there are any questions please feel free to contact me at 303-684-4706. > > > Thanks > > > Bill Lynn > > Secretary > > SNIA IP Storage Forum > > > > #### att1.htm has been deleted (was saved in repository My Attachments > Repository ->(Document link: Link to the attachment in the repository)) > from this note on 11 June 2001 by Julian Satran > > > > From owner-ips@ece.cmu.edu Mon Jun 18 23:14:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29169 for ; Mon, 18 Jun 2001 23:14:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5J1GQB15852 for ips-outgoing; Mon, 18 Jun 2001 21:16:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5ILROg00794 for ; Mon, 18 Jun 2001 17:27:24 -0400 (EDT) Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f5ILR2K02161; Mon, 18 Jun 2001 14:27:02 -0700 (PDT) Received: from tooting-fe.eng.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f5ILR2514603; Mon, 18 Jun 2001 14:27:02 -0700 (PDT) Received: (from beepy@localhost) by tooting-fe.eng.netapp.com (8.8.8+Sun/8.8.8) id OAA09292; Mon, 18 Jun 2001 14:27:02 -0700 (PDT) From: Brian Pawlowski Message-Id: <200106182127.OAA09292@tooting-fe.eng.netapp.com> Subject: Re: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion In-Reply-To: <9678C2B4D848D41187450090276D1FAE0AEFDADD@FMSMSX32> from "Zamer, Ahmad" at "Jun 18, 1 12:53:54 pm" To: ahmad.zamer@intel.com (Zamer, Ahmad) Date: Mon, 18 Jun 2001 14:27:02 -0700 (PDT) Cc: Black_David@emc.com, ips@ece.cmu.edu X-Mailer: ELM [version 2.4ME++ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The UNH site for the event: http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html dropped wording on requiring membership to any org as prerequisite for attendance. I assume this is what David was referring to regardless of the mail that was forwarded. Long live open protocols:-) beepy > Hi David, > > Just a clarification. > > The invitation sent out by Bill Lynn states that "This event is open to all > IP Storage > > Forum members and there will be a nominal fee of $250.00 per engineer > > attending. The current plan is to test to the iSCSI draft standards > > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a > > call > > for participation please respond with your company's intent to > > participate." > > Although opening the event to all may be a good idea, the invitation did not > go that far. > > Regards, > Ahmad Zamer > Intel Corporation > voice: 512-407-2155 > mail: ahmad.zamer@intel.com > > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, June 18, 2001 2:10 PM > To: ips@ece.cmu.edu > Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for > Participat ion > > > Since this topic has surfaced on this list, it is > my understanding that this plugfest is now open to > all participants, not just SNIA or UNH iSCSI consortium > members. > > FYI and thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > > -----Original Message----- > > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com] > > Sent: Monday, June 18, 2001 1:42 PM > > To: ips@ece.cmu.edu > > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for > > Participation > > > > > > > > Dear colleagues, > > > > I was asked by many of you what codes to use for the plugfest. I think you > > would want to consider using the already published codes for 07 (published > > on this list) as an alternative to 06. The transition to 07 will be > > easier > > and you will > > have far less interoperability issues. > > > > Regards, > > Julo > > ---------------------- Forwarded by Julian Satran/Haifa/IBM on 18-06-2001 > > 20:38 --------------------------- > > > > "Lynn, Bill" on 23-05-2001 19:37:42 > > > > Please respond to bill_lynn@btc.adaptec.com > > > > To: "'snia-ipsforum@snia.org'" > > cc: > > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation > > > > > > > > > > IP Storage Forum Member > > > > The IP Storage Forum is pleased to announce the first IP Storage Forum > > plugfest to be held on the 17th and 18th of July at the University of New > > Hampshire's InterOperability Lab. This event is open to all IP Storage > > Forum members and there will be a nominal fee of $250.00 per engineer > > attending. The current plan is to test to the iSCSI draft standards > > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a > > call > > for participation please respond with your company's intent to > > participate. > > Information we would like to know is: > > > > Company Name > > Contact Name (email and phone > > number) > > Number of engineers attending > > Number and types of products to be > > tested > > Protocol type and version > > implemented > > > > Logistical information should follow within the next two weeks. The goal > > of > > the plugfest is to do some low level protocol testing along with some > > higher > > level system testing. The information on types of products will determine > > the possible configurations we can construct. Please email the above > > information to - > > > > > > bill_lynn@corp.adaptec.com > > > > If there are any questions please feel free to contact me at 303-684-4706. > > > > > > Thanks > > > > > > Bill Lynn > > > > Secretary > > > > SNIA IP Storage Forum > > > > > > > > #### att1.htm has been deleted (was saved in repository My Attachments > > Repository ->(Document link: Link to the attachment in the repository)) > > from this note on 11 June 2001 by Julian Satran > > > > > From owner-ips@ece.cmu.edu Tue Jun 19 09:49:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21458 for ; Tue, 19 Jun 2001 09:49:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5JB6qh01839 for ips-outgoing; Tue, 19 Jun 2001 07:06:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5JB6og01835 for ; Tue, 19 Jun 2001 07:06:50 -0400 (EDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id LAA05260; Tue, 19 Jun 2001 11:06:24 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 19 Jun 2001 11:06:24 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 04:06:22 -0700 Message-ID: <9678C2B4D848D41187450090276D1FAE0AEFDAEF@FMSMSX32> From: "Zamer, Ahmad" To: "'Brian Pawlowski'" , "Zamer, Ahmad" Cc: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion Date: Tue, 19 Jun 2001 04:06:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, I recognize the overwhelming view that opening the plug fest to all is a good idea and hereby reverse my previous position 180 degrees to be exact. If so many people feel that an open event is good for all, then it better be. Even I can see the light. I look forward to a successful plug fest next month. Ahmad Zamer Intel Corporation voice: 512-407-2155 mail: ahmad.zamer@intel.com -----Original Message----- From: Brian Pawlowski [mailto:beepy@netapp.com] Sent: Monday, June 18, 2001 4:27 PM To: ahmad.zamer@intel.com Cc: Black_David@emc.com; ips@ece.cmu.edu Subject: Re: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion The UNH site for the event: http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html dropped wording on requiring membership to any org as prerequisite for attendance. I assume this is what David was referring to regardless of the mail that was forwarded. Long live open protocols:-) beepy > Hi David, > > Just a clarification. > > The invitation sent out by Bill Lynn states that "This event is open to all > IP Storage > > Forum members and there will be a nominal fee of $250.00 per engineer > > attending. The current plan is to test to the iSCSI draft standards > > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a > > call > > for participation please respond with your company's intent to > > participate." > > Although opening the event to all may be a good idea, the invitation did not > go that far. > > Regards, > Ahmad Zamer > Intel Corporation > voice: 512-407-2155 > mail: ahmad.zamer@intel.com > > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, June 18, 2001 2:10 PM > To: ips@ece.cmu.edu > Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for > Participat ion > > > Since this topic has surfaced on this list, it is > my understanding that this plugfest is now open to > all participants, not just SNIA or UNH iSCSI consortium > members. > > FYI and thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > > -----Original Message----- > > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com] > > Sent: Monday, June 18, 2001 1:42 PM > > To: ips@ece.cmu.edu > > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for > > Participation > > > > > > > > Dear colleagues, > > > > I was asked by many of you what codes to use for the plugfest. I think you > > would want to consider using the already published codes for 07 (published > > on this list) as an alternative to 06. The transition to 07 will be > > easier > > and you will > > have far less interoperability issues. > > > > Regards, > > Julo > > ---------------------- Forwarded by Julian Satran/Haifa/IBM on 18-06-2001 > > 20:38 --------------------------- > > > > "Lynn, Bill" on 23-05-2001 19:37:42 > > > > Please respond to bill_lynn@btc.adaptec.com > > > > To: "'snia-ipsforum@snia.org'" > > cc: > > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation > > > > > > > > > > IP Storage Forum Member > > > > The IP Storage Forum is pleased to announce the first IP Storage Forum > > plugfest to be held on the 17th and 18th of July at the University of New > > Hampshire's InterOperability Lab. This event is open to all IP Storage > > Forum members and there will be a nominal fee of $250.00 per engineer > > attending. The current plan is to test to the iSCSI draft standards > > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a > > call > > for participation please respond with your company's intent to > > participate. > > Information we would like to know is: > > > > Company Name > > Contact Name (email and phone > > number) > > Number of engineers attending > > Number and types of products to be > > tested > > Protocol type and version > > implemented > > > > Logistical information should follow within the next two weeks. The goal > > of > > the plugfest is to do some low level protocol testing along with some > > higher > > level system testing. The information on types of products will determine > > the possible configurations we can construct. Please email the above > > information to - > > > > > > bill_lynn@corp.adaptec.com > > > > If there are any questions please feel free to contact me at 303-684-4706. > > > > > > Thanks > > > > > > Bill Lynn > > > > Secretary > > > > SNIA IP Storage Forum > > > > > > > > #### att1.htm has been deleted (was saved in repository My Attachments > > Repository ->(Document link: Link to the attachment in the repository)) > > from this note on 11 June 2001 by Julian Satran > > > > > From owner-ips@ece.cmu.edu Tue Jun 19 14:33:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29880 for ; Tue, 19 Jun 2001 14:33:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5JGUvS25002 for ips-outgoing; Tue, 19 Jun 2001 12:30:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5JGUtg24998 for ; Tue, 19 Jun 2001 12:30:55 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Tue Jun 19 12:27:06 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Tue Jun 19 12:30:14 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id MAA18128; Tue, 19 Jun 2001 12:29:57 -0400 (EDT) Date: Tue, 19 Jun 2001 12:29:57 -0400 (EDT) Message-Id: <200106191629.MAA18128@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: esquicksall@hotmail.com Cc: ips@ece.cmu.edu Subject: Re: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, Here's where you had voted for those new opcodes :-) http://ips.pdl.cs.cmu.edu/mail/msg04757.html That said, wouldnt it be easier on everyone just to conform to draft-06 to the letter instead of carrying fragments of draft-07 into an interop test ? I presume the change-log for draft-07 has more important items than just opcodes. -Sandeep > > Can someone give us a pointer to the new op/codes? > > Eddy > > ----- Original Message ----- > From: > To: > Sent: Monday, June 18, 2001 1:42 PM > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation > > > > > > > Dear colleagues, > > > > I was asked by many of you what codes to use for the plugfest. I think you > > would want to consider using the already published codes for 07 (published > > on this list) as an alternative to 06. The transition to 07 will be > easier > > and you will > > have far less interoperability issues. > > > > Regards, > > Julo > > ---------------------- Forwarded by Julian Satran/Haifa/IBM on 18-06-2001 > > 20:38 --------------------------- > > > > "Lynn, Bill" on 23-05-2001 19:37:42 > > > > Please respond to bill_lynn@btc.adaptec.com > > > > To: "'snia-ipsforum@snia.org'" > > cc: > > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participation > > > > > > > > > > IP Storage Forum Member > > > > The IP Storage Forum is pleased to announce the first IP Storage Forum > > plugfest to be held on the 17th and 18th of July at the University of New > > Hampshire's InterOperability Lab. This event is open to all IP Storage > > Forum members and there will be a nominal fee of $250.00 per engineer > > attending. The current plan is to test to the iSCSI draft standards > > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a > > call > > for participation please respond with your company's intent to > participate. > > Information we would like to know is: > > > > Company Name > > Contact Name (email and phone > > number) > > Number of engineers attending > > Number and types of products to be > > tested > > Protocol type and version > > implemented > > > > Logistical information should follow within the next two weeks. The goal > > of > > the plugfest is to do some low level protocol testing along with some > > higher > > level system testing. The information on types of products will determine > > the possible configurations we can construct. Please email the above > > information to - > > > > > > bill_lynn@corp.adaptec.com > > > > If there are any questions please feel free to contact me at 303-684-4706. > > > > > > Thanks > > > > > > Bill Lynn > > > > Secretary > > > > SNIA IP Storage Forum > > > > > > > > #### att1.htm has been deleted (was saved in repository My Attachments > > Repository ->(Document link: Link to the attachment in the repository)) > > from this note on 11 June 2001 by Julian Satran > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 19 15:58:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02581 for ; Tue, 19 Jun 2001 15:58:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5JHvZY01705 for ips-outgoing; Tue, 19 Jun 2001 13:57:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5JHvXg01700 for ; Tue, 19 Jun 2001 13:57:33 -0400 (EDT) Received: (cpmta 10059 invoked from network); 19 Jun 2001 10:57:30 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.206) with SMTP; 19 Jun 2001 10:57:30 -0700 X-Sent: 19 Jun 2001 17:57:30 GMT From: "Douglas Otis" To: , Subject: RE: iSCSI: ICMP for Notification? Date: Tue, 19 Jun 2001 10:55:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0708F8@corpmx14.us.dg.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Although an ICMP code not understood is silently discarded, the only concern that I can see would be the rigor in ensuring this to be a rare signal as such a convention would not be a modification of ICMP. If there is a concern that SAN agents can not ensure proper use, perhaps a UDP based signaling protocol be devised instead as a standby alternative. A general signaling convention would allow notice for any SAN based protocol to query their management service. Rather than overloading SLP which only partially satisfies a management requirement, making a general signaling convention would not require additional (perhaps unneeded) servers added to support IPS related transports. A simple packet message with a small text string indicating the SAN domain that changed should be all that is required. Use the ICMP template on a UDP port pending the dubious approval of this crazy idea. This signal would be sent by the agent detecting the change to all servers advertising service affected by the domain. Although I still view the ICMP approach the cleanest solution as this protocol is already required by all IP stacks, adding a UDP filter at a specific port would be a small addition and comparable in overhead to any scheme devised for SLP. If the IPS group worked together, the best solution should have merit. If well presented, even the IESG should be receptive if it means fewer protocols are modified otherwise. As I have provided cover if required, do you see an problem discussing a stand alone signaling scheme? Doug > With my WG co-chair hat on, I want to discourage > Doug's proposed use of ICMP as a bad idea - I > can't imagine this ever making it to the IESG, > let alone being approved by them. Even the > experimental SLP notification would be a far > better approach. Please do not spend any further > list bandwidth on modifying ICMP specifically for > iSCSI. > > Thanks, > --David > > > -----Original Message----- > > From: Douglas Otis [SMTP:dotis@sanlight.net] > > Sent: Monday, June 18, 2001 2:46 PM > > To: ljlamers@mindspring.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: Wrapping up SendTargets > > > > LJ, > > > > Rather than mandating a non-existent standard (one modified to implement > > signaling), there is already a method of signaling using ICMP for other > > types of networking protocols. If this signaling is of a > critical nature, > > then adopting two ICMP codes for SAN Notice and Reply together with a > > means > > of logging running servers could provide an alternative. This would only > > entail registry of these codes. Finding a means to log running servers > > could be done with protocols like LDAP, SLP or equivalents. With the > > assumption that there will be agents running (servers perhaps) > that notice > > events that needs propagated, a list of servers would enable that > > function. > > It would then be incumbent upon the transport to further that signal to > > the > > clients to minimize this change to only those devices providing a SAN > > related service. The signal would be an indication to recheck > > configurations. > > > > > > Doug > > > > > Modified SLP should be the mandatory to implement. > > > > > > SendTargets is allowed under a grandfather agreement since it is > > > out there and should be carried in an Annex with a clear notation > > > that it is obsolete and is there because of pre-standard > > implementations. > > > > > > There is no need to mention iSNS - that is pretty nearly a vendor > > > specific approach to solving their perception of a problem, open > > > source available or not. > > > > > > > > > > > > > > > At 06/12/2001, Jim Hafner wrote: > > > > > > Folks, > > > > > > I think this thread is wandering off the field. > > > > > > The question is the issue of SendTargets. Let's remind > ourselves of the > > > original purpose of this proposed protocol: namely, it's > designed for a > > > storage box that contains one or more iSCSI target devices to report > > about > > > ITSELF, about what's in it! This includes both a list of the > > > iSCSI targets > > > it has PLUS the session coordination (via tags) of the various > > > IPaddress/tcpport combos it supports. > > > > > > In other words, it's job is to report about itself! The use of > > (unicast) > > > SLP as an alternative to SendTargets was focused exactly on the same > > > question: I ask a single box to tell me about itself. This function > > lies > > > between the two extremes of (a) static configuration of initiators and > > (b) > > > centralized management via iSNS style services. > > > > > > Somehow, someway, we need to define a protocol for a box to "tell us > > about > > > itself" in the absense of the centralized management infrastructure. > > That > > > seems critical to me. Even if I want to do static configuration, the > > guy > > > doing the configuration needs a way to get at the guts of each new box > > > he/she rolls into the environment. > > > > > > The choices are, it seems, that *every* box would need to support at > > least > > > one of: > > > a) SendTargets > > > b) modified SLP > > > c) iSNS > > > > > > What's the consensus on the protocol we aim for to solve this > > > middle ground > > > discovery problem? > > > Jim Hafner > > > > > > > From owner-ips@ece.cmu.edu Tue Jun 19 20:05:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08349 for ; Tue, 19 Jun 2001 20:05:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5JMAEG20612 for ips-outgoing; Tue, 19 Jun 2001 18:10:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5JMABg20605 for ; Tue, 19 Jun 2001 18:10:11 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA17550 for ; Tue, 19 Jun 2001 17:04:42 -0500 Received: from f3n42e (d03nm042h.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5JMA8S54004 for ; Tue, 19 Jun 2001 16:10:08 -0600 Subject: iSCSI: Clarification requested To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Prasenjit Sarkar" Date: Tue, 19 Jun 2001 15:09:55 -0700 X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/19/2001 03:10:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Can multiple iSCSI sessions share a TCP/IP connection? (We came across an implementation that does this). If I've missed text which disallows this, apologies in advance, Regards, Prasenjit Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose From owner-ips@ece.cmu.edu Tue Jun 19 21:30:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09949 for ; Tue, 19 Jun 2001 21:30:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5JNibj26579 for ips-outgoing; Tue, 19 Jun 2001 19:44:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.6.9.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5JNiZg26571 for ; Tue, 19 Jun 2001 19:44:35 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 407E91470 for ; Tue, 19 Jun 2001 17:44:33 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id BA8AC14B9 for ; Tue, 19 Jun 2001 17:44:32 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id QAA03064 for ; Tue, 19 Jun 2001 16:44:31 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA37DF; Tue, 19 Jun 2001 16:18:39 -0700 Message-ID: <3B2FDE5C.57FDF5AA@agilent.com> Date: Tue, 19 Jun 2001 16:21:00 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: London meeting logistics References: <0F31E5C394DAD311B60C00E029101A07080156A7@corpmx9.isus.emc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Since there are many people interested in both FC and non-FC IPS related items, why not push the non-FC related (iSCSI) discussions to the same meeting where the FC related items will be discussed? Better to travel to one meeting instead of two... -Matt Black_David@emc.com wrote: > > I've had several requests for information on the August > meetings of the IPS WG in London. This will be during > the IETF meeting week, August 6-10. The meeting will be > limited to iSCSI and related topics. Fibre Channel-related > topics, including FCIP and iFCP will be taken up in a > separate interim meeting (possibly later in August) > because the London IETF meeting week conflicts with > the T11 meeting week. > > Five hours (two 2.5 hour sessions) of meeting > time has been requested on the assumption that we > can almost certainly use it, but we may end up > with less due to not being able to take up the > Fibre Channel portion of our work and the expected > heavy demand for meeting time. > > At this point, no meeting schedule for London is available, > and when one appears - please DO NOT take it seriously!! > Draft schedules for IETF meetings are remarkably fluid > documents - meeting times and dates can and do change as > late as two weeks prior to the meeting week, as I've learned > the hard way ;-). > > The overall structure of the London IETF week should be similar > to Minneapolis (http://www.ietf.org/meetings/agenda_50.html) > - orientation talks and reception on Sunday, WG meetings > all day Monday-Thursday, plus Monday evening and Friday > morning. Tuesday and Wednesday evenings are set aside > for the social event and plenary sessions. Of course, > the dates/times of the various WG meetings in London will > be completely different from those in Minneapolis. > > One important difference from T10 and T11 meetings is that > there's a separate registration fee - $450 in advance, > $600 onsite. One fee covers as many WG meetings as one > wants to go to. Since that fee pays for the meeting space, > the hotel room block(s) are provided as a courtesy - unlike > T10 and T11, there's no ethical duty to stay in a room > block associated with the IETF meeting in order to help > pay for the meeting space. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jun 19 23:05:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12945 for ; Tue, 19 Jun 2001 23:05:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5K19tB01886 for ips-outgoing; Tue, 19 Jun 2001 21:09:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from newdev.harvard.edu ([140.247.60.212]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5K19rg01880 for ; Tue, 19 Jun 2001 21:09:53 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id VAA03226; Tue, 19 Jun 2001 21:09:50 -0400 (EDT) Date: Tue, 19 Jun 2001 21:09:50 -0400 (EDT) From: Scott Bradner Message-Id: <200106200109.VAA03226@newdev.harvard.edu> To: beepy@netapp.com, matt_wakeley@agilent.com Subject: Re: London meeting logistics Cc: Black_David@emc.com, ips@ece.cmu.edu Sender: owner-ips@ece.cmu.edu Precedence: bulk > Is it the case that the IP Storage meetings can be cancelled > because of an interim meeting? see http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt it specifically answers this question Scott From owner-ips@ece.cmu.edu Tue Jun 19 23:08:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA12970 for ; Tue, 19 Jun 2001 23:08:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5K1jgV04181 for ips-outgoing; Tue, 19 Jun 2001 21:45:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5K1jfg04176 for ; Tue, 19 Jun 2001 21:45:41 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 21:47:25 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070909@corpmx14.us.dg.com> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Subject: RE: iSCSI: ICMP for Notification? Date: Tue, 19 Jun 2001 21:42:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Doug, There are a whole bunch of problems here: - The IPS protocols are layer 5, ICMP is at layer 3. - ICMP is an unreliable delivery protocol without retransmits. - ICMP's interaction with IPSec can be peculiar, to put it mildly. - No new standard codes have been added to ICMP for the past five years. For all these reasons, I don't think use of ICMP for SAN management notifications is a good idea, and hence the WG should look elsewhere for a notification mechanism. Further discussion of this topic is not an appropriate use of list bandwidth. Please do not reply to the list. Thanks, --David > -----Original Message----- > From: Douglas Otis [SMTP:dotis@sanlight.net] > Sent: Tuesday, June 19, 2001 1:55 PM > To: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: ICMP for Notification? > > David, > > Although an ICMP code not understood is silently discarded, the only > concern > that I can see would be the rigor in ensuring this to be a rare signal as > such a convention would not be a modification of ICMP. If there is a > concern that SAN agents can not ensure proper use, perhaps a UDP based > signaling protocol be devised instead as a standby alternative. > > A general signaling convention would allow notice for any SAN based > protocol > to query their management service. Rather than overloading SLP which only > partially satisfies a management requirement, making a general signaling > convention would not require additional (perhaps unneeded) servers added > to > support IPS related transports. A simple packet message with a small text > string indicating the SAN domain that changed should be all that is > required. Use the ICMP template on a UDP port pending the dubious > approval > of this crazy idea. This signal would be sent by the agent detecting the > change to all servers advertising service affected by the domain. > Although > I still view the ICMP approach the cleanest solution as this protocol is > already required by all IP stacks, adding a UDP filter at a specific port > would be a small addition and comparable in overhead to any scheme devised > for SLP. > > If the IPS group worked together, the best solution should have merit. If > well presented, even the IESG should be receptive if it means fewer > protocols are modified otherwise. As I have provided cover if required, > do > you see an problem discussing a stand alone signaling scheme? > > Doug > > > With my WG co-chair hat on, I want to discourage > > Doug's proposed use of ICMP as a bad idea - I > > can't imagine this ever making it to the IESG, > > let alone being approved by them. Even the > > experimental SLP notification would be a far > > better approach. Please do not spend any further > > list bandwidth on modifying ICMP specifically for > > iSCSI. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Douglas Otis [SMTP:dotis@sanlight.net] > > > Sent: Monday, June 18, 2001 2:46 PM > > > To: ljlamers@mindspring.com; ips@ece.cmu.edu > > > Subject: RE: iSCSI: Wrapping up SendTargets > > > > > > LJ, > > > > > > Rather than mandating a non-existent standard (one modified to > implement > > > signaling), there is already a method of signaling using ICMP for > other > > > types of networking protocols. If this signaling is of a > > critical nature, > > > then adopting two ICMP codes for SAN Notice and Reply together with a > > > means > > > of logging running servers could provide an alternative. This would > only > > > entail registry of these codes. Finding a means to log running > servers > > > could be done with protocols like LDAP, SLP or equivalents. With the > > > assumption that there will be agents running (servers perhaps) > > that notice > > > events that needs propagated, a list of servers would enable that > > > function. > > > It would then be incumbent upon the transport to further that signal > to > > > the > > > clients to minimize this change to only those devices providing a SAN > > > related service. The signal would be an indication to recheck > > > configurations. > > > > > > > > > Doug > > > > > > > Modified SLP should be the mandatory to implement. > > > > > > > > SendTargets is allowed under a grandfather agreement since it is > > > > out there and should be carried in an Annex with a clear notation > > > > that it is obsolete and is there because of pre-standard > > > implementations. > > > > > > > > There is no need to mention iSNS - that is pretty nearly a vendor > > > > specific approach to solving their perception of a problem, open > > > > source available or not. > > > > > > > > > > > > > > > > > > > > At 06/12/2001, Jim Hafner wrote: > > > > > > > > Folks, > > > > > > > > I think this thread is wandering off the field. > > > > > > > > The question is the issue of SendTargets. Let's remind > > ourselves of the > > > > original purpose of this proposed protocol: namely, it's > > designed for a > > > > storage box that contains one or more iSCSI target devices to report > > > about > > > > ITSELF, about what's in it! This includes both a list of the > > > > iSCSI targets > > > > it has PLUS the session coordination (via tags) of the various > > > > IPaddress/tcpport combos it supports. > > > > > > > > In other words, it's job is to report about itself! The use of > > > (unicast) > > > > SLP as an alternative to SendTargets was focused exactly on the same > > > > question: I ask a single box to tell me about itself. This > function > > > lies > > > > between the two extremes of (a) static configuration of initiators > and > > > (b) > > > > centralized management via iSNS style services. > > > > > > > > Somehow, someway, we need to define a protocol for a box to "tell us > > > about > > > > itself" in the absense of the centralized management infrastructure. > > > That > > > > seems critical to me. Even if I want to do static configuration, > the > > > guy > > > > doing the configuration needs a way to get at the guts of each new > box > > > > he/she rolls into the environment. > > > > > > > > The choices are, it seems, that *every* box would need to support at > > > least > > > > one of: > > > > a) SendTargets > > > > b) modified SLP > > > > c) iSNS > > > > > > > > What's the consensus on the protocol we aim for to solve this > > > > middle ground > > > > discovery problem? > > > > Jim Hafner > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 20 00:06:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13997 for ; Wed, 20 Jun 2001 00:06:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5K2tNN08636 for ips-outgoing; Tue, 19 Jun 2001 22:55:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5K2tMg08630 for ; Tue, 19 Jun 2001 22:55:22 -0400 (EDT) Received: (cpmta 18984 invoked from network); 19 Jun 2001 19:55:15 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.206) with SMTP; 19 Jun 2001 19:55:15 -0700 X-Sent: 20 Jun 2001 02:55:15 GMT From: "Douglas Otis" To: , Subject: RE: iSCSI: Stand alone SAN network configuration change notice. Date: Tue, 19 Jun 2001 19:52:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <277DD60FB639D511AC0400B0D068B71E070909@corpmx14.us.dg.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, If you feel ICMP is off the table, then consider this suggestion as a general signaling mechanism using UDP. Although the affected programs may be at the application level, the change notification would be changes in assignments or function within the physical networks through a SAN bridge, router or switch. The suggestion that I made included notice and reply to overcome your delivery concern. If you look at RFC2521 (1999 experimental) you will see ICMP used to signal security failures. As the server and the SAN network is likely inside the firewall, there should be few such issues related to ICMP for this type of signaling concerning IPSec and may be viewed as a feature. I would not view this signal used at the client. The server should relay such concerns through the native transport. It is at the switch, router, bridge where this signal is likely to occur to perhaps inform higher level protocols of this network related change as is often the case. It is at that level of impact that I think deserves this consideration that may happen only once every five years. I have no trouble looking elsewhere such as UDP but I must say I do not agree with your conclusions. Considering such a signaling mechanism may impact the various transports if such signaling is standardized, reflector bandwidth should not be a major concern to resolve if changing existing network services are the best solution or if a more general and simpler scheme may be of greater utility. Doug > Doug, > > There are a whole bunch of problems here: > > - The IPS protocols are layer 5, ICMP is at > layer 3. > - ICMP is an unreliable delivery protocol without > retransmits. > - ICMP's interaction with IPSec can be peculiar, > to put it mildly. > - No new standard codes have been added to ICMP for > the past five years. > > For all these reasons, I don't think use of ICMP for SAN > management notifications is a good idea, and hence the > WG should look elsewhere for a notification mechanism. > Further discussion of this topic is not an appropriate > use of list bandwidth. Please do not reply to the list. > > Thanks, > --David > > > -----Original Message----- > > From: Douglas Otis [SMTP:dotis@sanlight.net] > > Sent: Tuesday, June 19, 2001 1:55 PM > > To: Black_David@emc.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: ICMP for Notification? > > > > David, > > > > Although an ICMP code not understood is silently discarded, the only > > concern > > that I can see would be the rigor in ensuring this to be a rare > signal as > > such a convention would not be a modification of ICMP. If there is a > > concern that SAN agents can not ensure proper use, perhaps a UDP based > > signaling protocol be devised instead as a standby alternative. > > > > A general signaling convention would allow notice for any SAN based > > protocol > > to query their management service. Rather than overloading SLP > which only > > partially satisfies a management requirement, making a general signaling > > convention would not require additional (perhaps unneeded) servers added > > to > > support IPS related transports. A simple packet message with a > small text > > string indicating the SAN domain that changed should be all that is > > required. Use the ICMP template on a UDP port pending the dubious > > approval > > of this crazy idea. This signal would be sent by the agent > detecting the > > change to all servers advertising service affected by the domain. > > Although > > I still view the ICMP approach the cleanest solution as this protocol is > > already required by all IP stacks, adding a UDP filter at a > specific port > > would be a small addition and comparable in overhead to any > scheme devised > > for SLP. > > > > If the IPS group worked together, the best solution should have > merit. If > > well presented, even the IESG should be receptive if it means fewer > > protocols are modified otherwise. As I have provided cover if required, > > do > > you see an problem discussing a stand alone signaling scheme? > > > > Doug > > > > > With my WG co-chair hat on, I want to discourage > > > Doug's proposed use of ICMP as a bad idea - I > > > can't imagine this ever making it to the IESG, > > > let alone being approved by them. Even the > > > experimental SLP notification would be a far > > > better approach. Please do not spend any further > > > list bandwidth on modifying ICMP specifically for > > > iSCSI. > > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Douglas Otis [SMTP:dotis@sanlight.net] > > > > Sent: Monday, June 18, 2001 2:46 PM > > > > To: ljlamers@mindspring.com; ips@ece.cmu.edu > > > > Subject: RE: iSCSI: Wrapping up SendTargets > > > > > > > > LJ, > > > > > > > > Rather than mandating a non-existent standard (one modified to > > implement > > > > signaling), there is already a method of signaling using ICMP for > > other > > > > types of networking protocols. If this signaling is of a > > > critical nature, > > > > then adopting two ICMP codes for SAN Notice and Reply > together with a > > > > means > > > > of logging running servers could provide an alternative. This would > > only > > > > entail registry of these codes. Finding a means to log running > > servers > > > > could be done with protocols like LDAP, SLP or equivalents. > With the > > > > assumption that there will be agents running (servers perhaps) > > > that notice > > > > events that needs propagated, a list of servers would enable that > > > > function. > > > > It would then be incumbent upon the transport to further that signal > > to > > > > the > > > > clients to minimize this change to only those devices > providing a SAN > > > > related service. The signal would be an indication to recheck > > > > configurations. > > > > > > > > > > > > Doug > > > > > > > > > Modified SLP should be the mandatory to implement. > > > > > > > > > > SendTargets is allowed under a grandfather agreement since it is > > > > > out there and should be carried in an Annex with a clear notation > > > > > that it is obsolete and is there because of pre-standard > > > > implementations. > > > > > > > > > > There is no need to mention iSNS - that is pretty nearly a vendor > > > > > specific approach to solving their perception of a problem, open > > > > > source available or not. > > > > > > > > > > > > > > > > > > > > > > > > > At 06/12/2001, Jim Hafner wrote: > > > > > > > > > > Folks, > > > > > > > > > > I think this thread is wandering off the field. > > > > > > > > > > The question is the issue of SendTargets. Let's remind > > > ourselves of the > > > > > original purpose of this proposed protocol: namely, it's > > > designed for a > > > > > storage box that contains one or more iSCSI target > devices to report > > > > about > > > > > ITSELF, about what's in it! This includes both a list of the > > > > > iSCSI targets > > > > > it has PLUS the session coordination (via tags) of the various > > > > > IPaddress/tcpport combos it supports. > > > > > > > > > > In other words, it's job is to report about itself! The use of > > > > (unicast) > > > > > SLP as an alternative to SendTargets was focused exactly > on the same > > > > > question: I ask a single box to tell me about itself. This > > function > > > > lies > > > > > between the two extremes of (a) static configuration of initiators > > and > > > > (b) > > > > > centralized management via iSNS style services. > > > > > > > > > > Somehow, someway, we need to define a protocol for a box > to "tell us > > > > about > > > > > itself" in the absense of the centralized management > infrastructure. > > > > That > > > > > seems critical to me. Even if I want to do static configuration, > > the > > > > guy > > > > > doing the configuration needs a way to get at the guts of each new > > box > > > > > he/she rolls into the environment. > > > > > > > > > > The choices are, it seems, that *every* box would need to > support at > > > > least > > > > > one of: > > > > > a) SendTargets > > > > > b) modified SLP > > > > > c) iSNS > > > > > > > > > > What's the consensus on the protocol we aim for to solve this > > > > > middle ground > > > > > discovery problem? > > > > > Jim Hafner > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jun 20 00:06:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14009 for ; Wed, 20 Jun 2001 00:06:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5K39A309477 for ips-outgoing; Tue, 19 Jun 2001 23:09:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (IDENT:root@va2mc.ummailbox.net [64.210.247.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5K398g09473 for ; Tue, 19 Jun 2001 23:09:08 -0400 (EDT) Received: from HQMailWeb.Crossroads.com [63.237.99.250:25] by va2mc.ummailbox.net with SMTP id J0619-2308-15fb01; Wed, 20 Jun 2001 03:08:07 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 19 Jun 2001 22:08:02 -0500 Subject: RE: (Start of) iSCSI ERT: handling for iSCSI response codes MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Tue, 19 Jun 2001 22:03:41 -0500 Message-ID: Thread-Topic: (Start of) iSCSI ERT: handling for iSCSI response codes Thread-Index: AcD4HhRPX6plxX8DRf2/IbbcepzfoQAtlfSA From: "Robert Griswold" To: Cc: X-OriginalArrivalTime: 20 Jun 2001 03:08:02.0183 (UTC) FILETIME=[378BC170:01C0F936] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f5K398g09474 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Mallikarjun: I am in complete agreement. We have discussed this (the separation of transport responses for errors from standard SCSI status CHECK CONDITIONS) and have been unclear on the method we would use to keep these separate. I have also commented on the overloading of the Response/Status field, and the confusion this would cause in handling PDUs expected to contain CHECK CONDITIONS. This is goodness, easy to understand and keeps iSCSI dependant on SCSI for this communication, which is where it should be addressed. Good work on consolidating this thread. Bob Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Monday, June 18, 2001 11:37 AM To: ips@ece.cmu.edu Subject: (Start of) iSCSI ERT: handling for iSCSI response codes Let me post the complete context for that email exchange, since I was the one proposing this change in ERT. Please take time to read these short messages, I would appreciate comments. One line quote from my message behind this proposal: "To summarize, IMHO, iSCSI is presumptively signaling the task conclusion with its response codes." Responding to Julian: >This type of handling will let us build independent of SCSI .... Julian, the fact is that we can not completely be "independent of SCSI" except we start building in redundant mechanisms like ACA at iSCSI level. I thought we were dropping the EnableACA "feature" precisely because we did not want to build in this redundancy! Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com ------------------------------------------------------------------------ -- Date: Thu, 07 Jun 2001 19:37:10 PDT To: cbm@rose.hp.com Subject: iSCSI ERT: handling for iSCSI response codes Cc: julian_satran@il.ibm.com, someshg@yahoo.com, venkat@rhapsodynetworks.com, steph@cs.uchicago.edu, ldalleore@snapserver.com, Black_David@emc.com, hufferd@us.ibm.com, kalman_meth@il.ibm.com In-Reply-To: <200106060116.SAA00914@core.rose.hp.com>; from "Mallikarjun C." at Jun 5, 101 6:16 pm Status: RO Team, After exchanging some messages with Ralph Weber and Ed Gardner, I am coming to the conclusion that all the error cases which result in "iSCSI response codes" in the SCSI Response PDU should in fact result in SCSI CHECK CONDITION - to result in ACA if NACA=1 was set for the failing command, ie. to kick in the regular SCSI processing. Following are defined in draft rev06 - 0x01 - Target Failure 0x02 - Delivery Subsystem Failure 0x03 - Unsolicited data rejected 0x04 - SNACK rejected Note that commands failing with any of these response codes would cause out-of-order execution for the follow-on commands - even with NACA=1, simply because iSCSI can not mandate ACA, a SCSI-ism, to enforce ordering (we dropped EnableACA kludge because of this reason). The solution I see is to instead have iSCSI mandate a standard SCSI CHECK CONDITION on these errors with the current response codes acting as detailed descriptions. It turns out there are already reasonable ASC/ASCQ values defined for these cases (for all SCSI device types) in SPC-2. Here they are - ASC ASCQ Means Target Failure -> 0x44 0x00 Internal Target Failure Delivery Subsystem -> 0x47 0x03 Information Unit CRC error Failure detected SNACK rejected -> -do - -do- (since the root cause is the same) Unsolicited data -> 0x49 0x00 Invalid Message Error rejected To summarize, I propose that iSCSI mandate CHECK CONDITION with the ASC/ASCQ values as shown above - instead of limiting to iSCSI response codes. This cleanly takes care of the ACA issue. There are precedents in SCSI Protocol standards like FCP-2 for mandating such behavior. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com ------------------------------------------------------------------------ - Date: Thu, 14 Jun 2001 10:58:04 PDT To: steph@cs.uchicago.edu Subject: Re: iSCSI ERT: handling for iSCSI response codes Cc: cbm@rose.hp.com, julian_satran@il.ibm.com, someshg@yahoo.com, venkat@rhapsodynetworks.com, ldalleore@snapserver.com, Black_David@emc.com, hufferd@us.ibm.com, kalman_meth@il.ibm.com In-Reply-To: <200106140242.f5E2g9603398@chmls20.mediaone.net>; from "Stephen Bailey" at Jun 13, 101 7:43 pm Status: RO Steph, Thanks for the message. >I'm not clear on what you're proposing for SNACK rejected, but, since >it's not CHECK CONDITION, I'm sure whatever you have in mind is fine, >but we need to document it better :^) Sorry, I was using proprietary (and confidential) shorthand, :-) Actually, I was proposing a CHECK CONDITION (0x47, 0x03) even for "SNACK rejected" since the "root cause is the same" - ie. a prior data integrity error! Keep in mind that employing SNACK means the task is already considered in progress by both parties - the target iSCSI is fabricating a SCSI Response PDU without its SCSI involvement, it's technically incorrect since the task is already instantiated at its SCSI layer. That's what the source of the problem here is. To summarize, IMHO, iSCSI is presumptively signaling the task conclusion with its response codes. The correct options are a) iSCSI should not deliver a SCSI Response at all, forcing a timeout and thus the standard SCSI recovery. OR b) iSCSI should mandate a CHECK CONDITION - which technically involves task cleanup at target SCSI layer, and leads to the right ordering semantics. My suggestion was ofcourse (b), for faster error recovery. I haven't seen a response from Julian yet, hope he's accommodating this in rev07! Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com > >Mallikarjun, > >> Comments? > >Hmm. Ok, I agree. > >For example, I never really thought: > >> 0x02 - Delivery Subsystem Failure > >was the right way to report in-band integrity errors. Delivery >subsystem failure usually means something that is not even detectable >by the target, like a timeout. As such, I agree that the target >shouldn't be responding this back. > >Yes, I have seen many FCP targets do exactly what you're suggesting >here. In fact 0xB 0x4700 (good ole SCSI parity error) is code for >many different protocol errors which are detectable and attributable >to a particular SCSI command. For example, bogus settings of FCP >F_CTL bits. > >So, assuming that Target Failure, Delivery Subsystem Failure are all >attributable to a SCSI command, I agree they should create CHECK >conditions. > >The place where response values are justified is if the error is >attributable to something other than a SCSI command, such as a task >management function. For example, task management function rejected >(which we don't seem to have). If we were anticipating any of these >as a response to task management, they should remain, or perhaps we >should define new, more specifically task management related responses >codes. > >I'm not clear on what you're proposing for SNACK rejected, but, since >it's not CHECK CONDITION, I'm sure whatever you have in mind is fine, >but we need to document it better :^) > >Steph > ------------------------------------------------------------------------ ------ >Steph, > >That is an interesting change in opinion. When I suggested the same thing >some releases ago for the same set of reasons >(I even suggested avoiding the response codes at all!) as there is no >noticeable difference in handling the heat of your response was felt at >6000 miles. > >However I am not sure anymore that given the need for a clearing action for >most of those cases that we should not keep >the treatment within the iSCSI layer and create an >iSCSI-exception-condition (for all iSCSI created responses) cleared through >an iSCSI task management function (clear-iSCSI-exception) and reject all >intervening commands. > >This type of handling will let us build independent of SCSI and keep the >layering purists happy. > >Regards, >Julo > From owner-ips@ece.cmu.edu Wed Jun 20 00:07:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14035 for ; Wed, 20 Jun 2001 00:07:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5K2URM07044 for ips-outgoing; Tue, 19 Jun 2001 22:30:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5K13Bg01419 for ; Tue, 19 Jun 2001 21:03:11 -0400 (EDT) Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f5K126K13775; Tue, 19 Jun 2001 18:02:06 -0700 (PDT) Received: from tooting-fe.eng.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f5K126A28161; Tue, 19 Jun 2001 18:02:06 -0700 (PDT) Received: (from beepy@localhost) by tooting-fe.eng.netapp.com (8.8.8+Sun/8.8.8) id SAA14819; Tue, 19 Jun 2001 18:02:04 -0700 (PDT) From: Brian Pawlowski Message-Id: <200106200102.SAA14819@tooting-fe.eng.netapp.com> Subject: Re: London meeting logistics In-Reply-To: <3B2FDE5C.57FDF5AA@agilent.com> from Matt Wakeley at "Jun 19, 1 04:21:00 pm" To: matt_wakeley@agilent.com Date: Tue, 19 Jun 2001 18:02:04 -0700 (PDT) Cc: Black_David@emc.com, ips@ece.cmu.edu X-Mailer: ELM [version 2.4ME++ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Since there are many people interested in both FC and non-FC IPS related > items, why not push the non-FC related (iSCSI) discussions to the same meeting > where the FC related items will be discussed? > > Better to travel to one meeting instead of two... Wow. You just created two trips for me... So, I view the IP Storage activities as part of the IETF. Interim meetings are certainly allowable - with permission, but meetings should focus within the IETF. Of course most work occurs outside meetings and/or on mail lists. Is it the case that the IP Storage meetings can be cancelled because of an interim meeting? beepy From owner-ips@ece.cmu.edu Wed Jun 20 11:44:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11591 for ; Wed, 20 Jun 2001 11:44:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KE6gu01996 for ips-outgoing; Wed, 20 Jun 2001 10:06:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5KE6fg01991 for ; Wed, 20 Jun 2001 10:06:41 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA06398; Wed, 20 Jun 2001 10:06:34 -0400 (EDT) Message-ID: <3B30ACF1.E5C50A49@cisco.com> Date: Wed, 20 Jun 2001 09:02:25 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: John Hufferd CC: ips@ece.cmu.edu Subject: Re: iSCSI: Wrapping up SendTargets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This thread turned out more interesting than I had expected, but anyway, after reading through the messages sent while I was gone, it looks like we at least have some consensus on keeping SendTargets. I would like to see John's option #2 as well. Currently, SendTargets is documented in the naming & discovery document; where should we put it in the iSCSI spec? We will also need to close on some of the previous threads about aggregation tags, iteration, etc. It looks like we should continue the thread on the future (SLP, iSNS, etc.) discovery stuff, but I should have started that one separately. -- Mark John Hufferd wrote: > > iSCSI Team, > I think that Jim has said it well. I had a proposal about an Annex, for > the SendTargets, but whether we do that or not, I am getting the feeling > that most folks think, at least for this version of the protocol that we > keep SendTargets, and the subset that can be used as a Report Portal > Groups. Even Mark, even though he thought he could Hack the SLP Source > code to do a similar thing, thought that it was best to keep SendTargets. > > I would like to propose that we Close on Keeping the SendTargets command, > and the subset that is either Report Portal Groups or SendTargets Target Name> (which returns only the information for that target only). > > Now as to where we put the command. I suggested an Annex, but can clearly > live with it in the Main document. I seemed to get very little support for > the idea of the Annex, and since I think that the functions of Report > Portal Groups, must be part of the base, I would like to suggest that we > either > 1) Place the SendTargets in the Annex, and put a Report Portal Groups in > the main document, or > 2) Keep the Send Targets in the Main Document and add the argument of > > > Please state your positions > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Internet address: hufferd@us.ibm.com > > Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 06/12/2001 04:56:10 PM > > Sent by: owner-ips@ece.cmu.edu > > To: ips@ece.cmu.edu > cc: > Subject: RE: iSCSI: Wrapping up SendTargets > > Folks, > > I think this thread is wandering off the field. > > The question is the issue of SendTargets. Let's remind ourselves of the > original purpose of this proposed protocol: namely, it's designed for a > storage box that contains one or more iSCSI target devices to report about > ITSELF, about what's in it! This includes both a list of the iSCSI targets > it has PLUS the session coordination (via tags) of the various > IPaddress/tcpport combos it supports. > > In other words, it's job is to report about itself! The use of (unicast) > SLP as an alternative to SendTargets was focused exactly on the same > question: I ask a single box to tell me about itself. This function lies > between the two extremes of (a) static configuration of initiators and (b) > centralized management via iSNS style services. > > Somehow, someway, we need to define a protocol for a box to "tell us about > itself" in the absense of the centralized management infrastructure. That > seems critical to me. Even if I want to do static configuration, the guy > doing the configuration needs a way to get at the guts of each new box > he/she rolls into the environment. > > The choices are, it seems, that *every* box would need to support at least > one of: > a) SendTargets > b) modified SLP > c) iSNS > > What's the consensus on the protocol we aim for to solve this middle ground > discovery problem? > Jim Hafner -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jun 20 11:49:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11729 for ; Wed, 20 Jun 2001 11:49:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KDb4X29824 for ips-outgoing; Wed, 20 Jun 2001 09:37:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5KDb2g29818 for ; Wed, 20 Jun 2001 09:37:02 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 09:38:46 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E07090C@corpmx14.us.dg.com> From: Black_David@emc.com To: dotis@sanlight.net, ips@ece.cmu.edu Subject: RE: iSCSI: Stand alone SAN network configuration change notice. Date: Wed, 20 Jun 2001 09:34:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > If you feel ICMP is off the table, then consider this suggestion as a > general signaling mechanism using UDP. Like SNMP Notifications? I'd suggest looking there as one possibility. > Although the affected programs may > be at the application level, the change notification would be changes in > assignments or function within the physical networks through a SAN bridge, > router or switch. The suggestion that I made included notice and reply to > overcome your delivery concern. In other words, a new reliable delivery mechanism. That's not likely to make it through the transport ADs. > If you look at RFC2521 (1999 experimental) > you will see ICMP used to signal security failures. That's for IPsec, which is layer 3, whereas all the IPS protocols are layer 5. The fact that this can be made to work doesn't make it a good design decision from an architectural standpoint. > As the server and the > SAN network is likely inside the firewall, there should be few such issues > related to ICMP for this type of signaling concerning IPSec and may be > viewed as a feature. Definitely a bad design assumption. IPS protocols will almost certainly run over VPN links that are implemented by IPSec security gateways, and ICMP has a poor track record of interaction with such gateways. > I have no trouble > looking elsewhere such as UDP but I must say I do not agree with your > conclusions. Considering such a signaling mechanism may impact the various > transports if such signaling is standardized, reflector bandwidth should not > be a major concern to resolve if changing existing network services are the > best solution or if a more general and simpler scheme may be of greater > utility. In case I'm not making myself clear - I have no problem with work on notification issues and use of the reflector to explore solutions (e.g., see my previous comments on iSNS's ability to handle this). My issue is solely with ICMP - extending it is not an appropriate approach to this area and hence I am strongly advising the WG to look elsewhere. Considering Doug's past complaint that: It would seem that IPS can do anything out of the architectural norm they desire I'm quite surprised to find Doug pushing something that is clearly "out of the architectural norm". Do I need to get out a bigger clue-by-four? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jun 20 13:48:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15766 for ; Wed, 20 Jun 2001 13:48:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KFjPY09621 for ips-outgoing; Wed, 20 Jun 2001 11:45:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com (sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5KFjNg09617 for ; Wed, 20 Jun 2001 11:45:23 -0400 (EDT) Received: from cs.uchicago.edu (dynamite-72.sandburst.com [172.16.5.72]) by sandmail.sandburst.com (Postfix) with ESMTP id 0902A9400A for ; Wed, 20 Jun 2001 11:45:19 -0400 (EDT) To: ips@ece.cmu.edu Subject: Re: iSCSI: Clarification requested In-Reply-To: Message from "Prasenjit Sarkar" of "Tue, 19 Jun 2001 15:09:55 PDT." References: Date: Wed, 20 Jun 2001 11:45:12 -0400 From: Stephen Bailey Message-Id: <20010620154519.0902A9400A@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Prasenjit, > Can multiple iSCSI sessions share a TCP/IP connection? Huh? My knee jerk is, absolutely not! How could that work? How are the PDUs for different sessions distinguished? Independently of that, the login process doesn't allow it. There's only one SID pair exchanged, with a Login/Login Response and then the connection is in full feature mode (at which point, you couldn't exchange more SIDs). > (We came across an implementation that does this). So, I'll bite, how DOES said implementation do this? Wow. Thanks, Steph From owner-ips@ece.cmu.edu Wed Jun 20 13:50:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15869 for ; Wed, 20 Jun 2001 13:50:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KFv9610567 for ips-outgoing; Wed, 20 Jun 2001 11:57:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com (sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5KFv8g10561 for ; Wed, 20 Jun 2001 11:57:08 -0400 (EDT) Received: from cs.uchicago.edu (dynamite-72.sandburst.com [172.16.5.72]) by sandmail.sandburst.com (Postfix) with ESMTP id 235079400A for ; Wed, 20 Jun 2001 11:57:08 -0400 (EDT) To: ips@ece.cmu.edu Subject: Re: iSCSI:Text field in Asynchronous Message In-Reply-To: Message from "Tanjore K. Suresh" of "Thu, 14 Jun 2001 15:03:07 PDT." <200106142201.PAA01189@phys-ha3mpka.Eng.Sun.COM> References: <200106142201.PAA01189@phys-ha3mpka.Eng.Sun.COM> Date: Wed, 20 Jun 2001 11:57:01 -0400 From: Stephen Bailey Message-Id: <20010620155708.235079400A@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk > Will there ever be a need for a Target to send an asynchronous Text message > to the initiators I can't speak to need, but it is allowed. My reading of the intent of the spec (I'm not sure it says this as well as it could, or even at all), is that targets can CERTAINLY initiate X-* text message exchanges during full-feature mode. The semantics of an X-* message is entirely outside the spec, so sending an X-* message may be a one-way operation (no response required), or a multiway, handshaking deal, or whatever. You could perform arbitrary vendor specific (or standardized elsewhere) communication among targets and initiators using X-* messages. However, if your target wants to be a multitransport creature (||SCSI, FCP & iSCSI), you're better off doing this communication using some SCSI mechanism. SCSI doesn't give you a good, ubiquitous way for target-initiated messaging though, but there are work-arounds. What's often used is vendor specific sense on the next command completion signal that the target wants to say something to the initiator. In other words, sure you can, and I suspect that initially many will use this mechanism, but there are some strong reasons that it might not take off as THE WAY to do out-of-band communcation. Steph From owner-ips@ece.cmu.edu Wed Jun 20 15:12:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18880 for ; Wed, 20 Jun 2001 15:12:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KGwhN15356 for ips-outgoing; Wed, 20 Jun 2001 12:58:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5KGwVg15346 for ; Wed, 20 Jun 2001 12:58:31 -0400 (EDT) Received: from breinhold ([140.186.66.73]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f5KGwQ609896; Wed, 20 Jun 2001 12:58:26 -0400 (EDT) From: "Barry Reinhold" To: "Zamer, Ahmad" , "'Brian Pawlowski'" Cc: , Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion Date: Wed, 20 Jun 2001 12:55:15 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <9678C2B4D848D41187450090276D1FAE0AEFDAEF@FMSMSX32> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Having spent 10 years architecting and running the IOL I would like to note one thing. The issue about the "open" plugfest is really one of costs. Not the cost of the plugfest but of the iSCSI consortium itself. The iSCSI consortium essentially produces services and tools to improve iSCSI interoperability. The cost to cover this comes from membership fees in the iSCSI consortium. There is no profit in the IOL, so the flow of venture capitol dollars is pretty low. The issue for the IOL is how to fund the development. When the plugfest is "open" the number of companies that join the consortium is small, as there is no real reason to join it until it offers testing services (some development completes). This reduces the work being done towards the development of an open conformance test, and other interoperability tools and services -- dragging the process out longer. Having watched this process over the years from the inside I think we (the iSCSI community) are better off if we require membership. This way we all have a hard core reason to pay the membership fee in a timely manner. This will get us tools and interoperability testing services sooner. A compromise position might be to have membership required in the first plug fest but not in future ones. That way enough companies will get involved in the consortium that sufficient revenue is generated to ensure that the work moves forward but the overall process remains open. Future membership will be driven by the testing services that should then be in place. There are other approaches, but based on my past experience, requiring membership (and allowing some companies to request exceptions through UNH) is the best way to get this process moving. >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Zamer, Ahmad >Sent: Tuesday, June 19, 2001 7:06 AM >To: 'Brian Pawlowski'; Zamer, Ahmad >Cc: Black_David@emc.com; ips@ece.cmu.edu >Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >Participat ion > > >Hi, > >I recognize the overwhelming view that opening the plug fest to all is a >good idea and hereby reverse my previous position 180 degrees to be exact. >If so many people feel that an open event is good for all, then it better >be. > >Even I can see the light. > >I look forward to a successful plug fest next month. > >Ahmad Zamer >Intel Corporation >voice: 512-407-2155 >mail: ahmad.zamer@intel.com > >-----Original Message----- >From: Brian Pawlowski [mailto:beepy@netapp.com] >Sent: Monday, June 18, 2001 4:27 PM >To: ahmad.zamer@intel.com >Cc: Black_David@emc.com; ips@ece.cmu.edu >Subject: Re: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >Participat ion > > >The UNH site for the event: > > http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html > >dropped wording on requiring membership to any org as prerequisite for >attendance. > >I assume this is what David was referring to regardless of the mail >that was forwarded. > >Long live open protocols:-) > >beepy > >> Hi David, >> >> Just a clarification. >> >> The invitation sent out by Bill Lynn states that "This event is open to >all >> IP Storage >> > Forum members and there will be a nominal fee of $250.00 per engineer >> > attending. The current plan is to test to the iSCSI draft standards >> > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a >> > call >> > for participation please respond with your company's intent to >> > participate." >> >> Although opening the event to all may be a good idea, the invitation did >not >> go that far. >> >> Regards, >> Ahmad Zamer >> Intel Corporation >> voice: 512-407-2155 >> mail: ahmad.zamer@intel.com >> >> >> -----Original Message----- >> From: Black_David@emc.com [mailto:Black_David@emc.com] >> Sent: Monday, June 18, 2001 2:10 PM >> To: ips@ece.cmu.edu >> Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >> Participat ion >> >> >> Since this topic has surfaced on this list, it is >> my understanding that this plugfest is now open to >> all participants, not just SNIA or UNH iSCSI consortium >> members. >> >> FYI and thanks, >> --David >> >> --------------------------------------------------- >> David L. Black, Senior Technologist >> EMC Corporation, 42 South St., Hopkinton, MA 01748 >> +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 >> black_david@emc.com Mobile: +1 (978) 394-7754 >> --------------------------------------------------- >> >> >> > -----Original Message----- >> > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com] >> > Sent: Monday, June 18, 2001 1:42 PM >> > To: ips@ece.cmu.edu >> > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >> > Participation >> > >> > >> > >> > Dear colleagues, >> > >> > I was asked by many of you what codes to use for the plugfest. I think >you >> > would want to consider using the already published codes for 07 >(published >> > on this list) as an alternative to 06. The transition to 07 will be >> > easier >> > and you will >> > have far less interoperability issues. >> > >> > Regards, >> > Julo >> > ---------------------- Forwarded by Julian Satran/Haifa/IBM on >18-06-2001 >> > 20:38 --------------------------- >> > >> > "Lynn, Bill" on 23-05-2001 19:37:42 >> > >> > Please respond to bill_lynn@btc.adaptec.com >> > >> > To: "'snia-ipsforum@snia.org'" >> > cc: >> > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >Participation >> > >> > >> > >> > >> > IP Storage Forum Member >> > >> > The IP Storage Forum is pleased to announce the first IP Storage Forum >> > plugfest to be held on the 17th and 18th of July at the University of >New >> > Hampshire's InterOperability Lab. This event is open to all IP Storage >> > Forum members and there will be a nominal fee of $250.00 per engineer >> > attending. The current plan is to test to the iSCSI draft standards >> > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a >> > call >> > for participation please respond with your company's intent to >> > participate. >> > Information we would like to know is: >> > >> > Company Name >> > Contact Name (email and phone >> > number) >> > Number of engineers attending >> > Number and types of products to >be >> > tested >> > Protocol type and version >> > implemented >> > >> > Logistical information should follow within the next two weeks. The >goal >> > of >> > the plugfest is to do some low level protocol testing along with some >> > higher >> > level system testing. The information on types of products will >determine >> > the possible configurations we can construct. Please email the above >> > information to - >> > >> > >> > bill_lynn@corp.adaptec.com >> > >> > If there are any questions please feel free to contact me at >303-684-4706. >> > >> > >> > Thanks >> > >> > >> > Bill Lynn >> > >> > Secretary >> > >> > SNIA IP Storage Forum >> > >> > >> > >> > #### att1.htm has been deleted (was saved in repository My Attachments >> > Repository ->(Document link: Link to the attachment in the repository)) >> > from this note on 11 June 2001 by Julian Satran >> > >> > >> > > From owner-ips@ece.cmu.edu Wed Jun 20 17:46:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24054 for ; Wed, 20 Jun 2001 17:46:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KJvX629349 for ips-outgoing; Wed, 20 Jun 2001 15:57:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5KJvVg29344 for ; Wed, 20 Jun 2001 15:57:31 -0400 (EDT) Received: (cpmta 27388 invoked from network); 20 Jun 2001 12:36:02 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.214) with SMTP; 20 Jun 2001 12:36:02 -0700 X-Sent: 20 Jun 2001 19:36:02 GMT From: "Douglas Otis" To: , Subject: RE: iSCSI: Stand alone SAN network configuration change notice. Date: Wed, 20 Jun 2001 12:33:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <277DD60FB639D511AC0400B0D068B71E07090C@corpmx14.us.dg.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Would you describe DNS using UDP as a reliable transport? A simple single packet request and response? The EnterpriseSpecific Trap with SNMP on UDP port 162 could be used. How would you implement acknowledgement? Would you generate another trap indicating some expected action was not seen at some interval? With all the 'below the transport' filtering being suggested for various IPS protocols, I tend to loose track as where to place these within the general scheme but I am happy to accept your clue-by-four. :) I need all the clues I can get and found your input beneficial. My concerns within the statement to Ran was reflecting on his bashing of the methods of establishing security together with my perception of an indicated need to change every protocol (which generated this thread). I am waiting for further clarifications within the next iteration of iSCSI to see how Ran's bullets are dodged. I saw my suggestion of an added ICMP signal as the lesser of the evils with an easy UDP back door. Equipment likely to be generating these messages will be interested in communicating to the general machine (server) rather than any particular application and not likely tied directly to the end points of the transport. I do not see these messages directly associated with any IPS transport, but rather a general network status notification. I tend to view that level of communication rightfully done using the venerable ICMP. That I see as the norm, but I could be wrong. RFC1157: 4.1.6.7. The enterpriseSpecific Trap A enterpriseSpecific(6) trap signifies that the sending protocol entity recognizes that some enterprise-specific event has occurred. The specific-trap field identifies the particular trap which occurred. Doug > > If you feel ICMP is off the table, then consider this suggestion as a > > general signaling mechanism using UDP. > > Like SNMP Notifications? I'd suggest looking there as one possibility. > > > Although the affected programs may > > be at the application level, the change notification would be changes in > > assignments or function within the physical networks through a > SAN bridge, > > router or switch. The suggestion that I made included notice > and reply to > > overcome your delivery concern. > > In other words, a new reliable delivery mechanism. That's not likely to > make it through the transport ADs. > > > If you look at RFC2521 (1999 experimental) > > you will see ICMP used to signal security failures. > > That's for IPsec, which is layer 3, whereas all the IPS protocols > are layer > 5. > The fact that this can be made to work doesn't make it a good design > decision from an architectural standpoint. > > > As the server and the > > SAN network is likely inside the firewall, there should be few > such issues > > related to ICMP for this type of signaling concerning IPSec and may be > > viewed as a feature. > > Definitely a bad design assumption. IPS protocols will almost certainly > run over VPN links that are implemented by IPSec security gateways, > and ICMP has a poor track record of interaction with such gateways. > > > I have no trouble > > looking elsewhere such as UDP but I must say I do not agree with your > > conclusions. Considering such a signaling mechanism may impact the > various > > transports if such signaling is standardized, reflector bandwidth should > not > > be a major concern to resolve if changing existing network services are > the > > best solution or if a more general and simpler scheme may be of greater > > utility. > > In case I'm not making myself clear - I have no problem with work on > notification issues and use of the reflector to explore solutions (e.g., > see my previous comments on iSNS's ability to handle this). My issue > is solely with ICMP - extending it is not an appropriate approach to this > area and hence I am strongly advising the WG to look elsewhere. > > Considering Doug's past complaint that: > > It would seem that IPS can do anything out of the architectural norm > they > desire > > I'm quite surprised to find Doug pushing something that is clearly > "out of the architectural norm". Do I need to get out a bigger > clue-by-four? > > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Wed Jun 20 17:50:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24198 for ; Wed, 20 Jun 2001 17:50:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KKbkn02401 for ips-outgoing; Wed, 20 Jun 2001 16:37:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5KKbjg02396 for ; Wed, 20 Jun 2001 16:37:45 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel1.hp.com (Postfix) with ESMTP id CEB5636D; Wed, 20 Jun 2001 16:37:44 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 971801F512; Wed, 20 Jun 2001 16:36:53 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 16:37:42 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0912B@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: London meeting logistics Date: Wed, 20 Jun 2001 16:37:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Your original post regarding the schedule for IPS meetings (http://ips.pdl.cs.cmu.edu/mail/msg04695.html) speculated that the IPS FC meeting would include security discussions. Is this still the intent? If so, that makes the group of people inconvenienced by separate meeting larger - those that are only interested in iSCSI would now have to also attend the T10-related IPS meeting. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, June 15, 2001 5:02 PM > To: ips@ece.cmu.edu > Subject: London meeting logistics > > > I've had several requests for information on the August > meetings of the IPS WG in London. This will be during > the IETF meeting week, August 6-10. The meeting will be > limited to iSCSI and related topics. Fibre Channel-related > topics, including FCIP and iFCP will be taken up in a > separate interim meeting (possibly later in August) > because the London IETF meeting week conflicts with > the T11 meeting week. > > Five hours (two 2.5 hour sessions) of meeting > time has been requested on the assumption that we > can almost certainly use it, but we may end up > with less due to not being able to take up the > Fibre Channel portion of our work and the expected > heavy demand for meeting time. > > At this point, no meeting schedule for London is available, > and when one appears - please DO NOT take it seriously!! > Draft schedules for IETF meetings are remarkably fluid > documents - meeting times and dates can and do change as > late as two weeks prior to the meeting week, as I've learned > the hard way ;-). > > The overall structure of the London IETF week should be similar > to Minneapolis (http://www.ietf.org/meetings/agenda_50.html) > - orientation talks and reception on Sunday, WG meetings > all day Monday-Thursday, plus Monday evening and Friday > morning. Tuesday and Wednesday evenings are set aside > for the social event and plenary sessions. Of course, > the dates/times of the various WG meetings in London will > be completely different from those in Minneapolis. > > One important difference from T10 and T11 meetings is that > there's a separate registration fee - $450 in advance, > $600 onsite. One fee covers as many WG meetings as one > wants to go to. Since that fee pays for the meeting space, > the hotel room block(s) are provided as a courtesy - unlike > T10 and T11, there's no ethical duty to stay in a room > block associated with the IETF meeting in order to help > pay for the meeting space. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Wed Jun 20 19:28:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26315 for ; Wed, 20 Jun 2001 19:28:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KLSei06214 for ips-outgoing; Wed, 20 Jun 2001 17:28:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5KLSdg06209 for ; Wed, 20 Jun 2001 17:28:39 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA21112; Wed, 20 Jun 2001 17:28:27 -0400 (EDT) Message-ID: <3B311481.51C2E0E@cisco.com> Date: Wed, 20 Jun 2001 16:24:17 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Stephen Bailey CC: ips@ece.cmu.edu Subject: Re: iSCSI: Clarification requested References: <20010620154519.0902A9400A@sandmail.sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We implemented a similar thing early last year, which allowed multiple targets to be accessed on a session, but only one session on the connection. There's no session ID in the PDU headers, so multiple sessions on a connection could probably not be done anyway. We later decided that multiplexing targets on a session was just not worth doing. I think that if it hasn't been clearly stated already, the iSCSI spec should say: 1 initiator-target pair per session 1 session per connection The MIB reflects this model. -- Mark Stephen Bailey wrote: > > Prasenjit, > > > Can multiple iSCSI sessions share a TCP/IP connection? > > Huh? My knee jerk is, absolutely not! How could that work? How are > the PDUs for different sessions distinguished? > > Independently of that, the login process doesn't allow it. There's > only one SID pair exchanged, with a Login/Login Response and then the > connection is in full feature mode (at which point, you couldn't > exchange more SIDs). > > > (We came across an implementation that does this). > > So, I'll bite, how DOES said implementation do this? > > Wow. > > Thanks, > Steph -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jun 20 19:29:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26328 for ; Wed, 20 Jun 2001 19:29:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KJ5sj25290 for ips-outgoing; Wed, 20 Jun 2001 15:05:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from med.corp.rhapsodynetworks.com (64-160-62-201.rhapsodynetworks.com [64.160.62.201] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5KJ5qg25286 for ; Wed, 20 Jun 2001 15:05:52 -0400 (EDT) Received: by med.corp.rhapsodynetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 12:05:38 -0700 Message-ID: <45BEF1D68145D51186C100B0D0AABE6506CE96@med.corp.rhapsodynetworks.com> From: Dennis Young To: "'Barry Reinhold'" , "Zamer, Ahmad" , "'Brian Pawlowski'" Cc: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion Date: Wed, 20 Jun 2001 12:05:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Is there any thought about making a longer term interoperability test setup on the Internet (make it private using VPN if security is a concern). Companies that build iSCSI switches can connect their gears to this network from their own facilities, same for storage device and HBA vendors. The current IOL or other organizations can manage the network and operation policy such as scheduling, addition and removal of equipments, etc. This is not my idea, just something I overheard in a storage conference. -dennis >-----Original Message----- >From: Barry Reinhold [mailto:bbrtrebia@mediaone.net] >Sent: Wednesday, June 20, 2001 9:55 AM >To: Zamer, Ahmad; 'Brian Pawlowski' >Cc: Black_David@emc.com; ips@ece.cmu.edu >Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >Participat ion > > >Having spent 10 years architecting and running the IOL I would >like to note >one thing. The issue about the "open" plugfest is really one >of costs. Not >the cost of the plugfest but of the iSCSI consortium itself. The iSCSI >consortium essentially produces services and tools to improve iSCSI >interoperability. The cost to cover this comes from membership >fees in the >iSCSI consortium. There is no profit in the IOL, so the flow of venture >capitol dollars is pretty low. The issue for the IOL is how to fund the >development. >When the plugfest is "open" the number of companies that join >the consortium >is small, as there is no real reason to join it until it offers testing >services (some development completes). This reduces the work being done >towards the development of an open conformance test, and other >interoperability tools and services -- dragging the process out longer. >Having watched this process over the years from the inside I >think we (the >iSCSI community) are better off if we require membership. This >way we all >have a hard core reason to pay the membership fee in a timely >manner. This >will get us tools and interoperability testing services sooner. >A compromise position might be to have membership required in >the first plug >fest but not in future ones. That way enough companies will >get involved in >the consortium that sufficient revenue is generated to ensure >that the work >moves forward but the overall process remains open. Future >membership will >be driven by the testing services that should then be in place. >There are other approaches, but based on my past experience, requiring >membership (and allowing some companies to request exceptions >through UNH) >is the best way to get this process moving. > >>-----Original Message----- >>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >>Zamer, Ahmad >>Sent: Tuesday, June 19, 2001 7:06 AM >>To: 'Brian Pawlowski'; Zamer, Ahmad >>Cc: Black_David@emc.com; ips@ece.cmu.edu >>Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>Participat ion >> >> >>Hi, >> >>I recognize the overwhelming view that opening the plug fest >to all is a >>good idea and hereby reverse my previous position 180 degrees >to be exact. >>If so many people feel that an open event is good for all, >then it better >>be. >> >>Even I can see the light. >> >>I look forward to a successful plug fest next month. >> >>Ahmad Zamer >>Intel Corporation >>voice: 512-407-2155 >>mail: ahmad.zamer@intel.com >> >>-----Original Message----- >>From: Brian Pawlowski [mailto:beepy@netapp.com] >>Sent: Monday, June 18, 2001 4:27 PM >>To: ahmad.zamer@intel.com >>Cc: Black_David@emc.com; ips@ece.cmu.edu >>Subject: Re: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>Participat ion >> >> >>The UNH site for the event: >> >> http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html >> >>dropped wording on requiring membership to any org as prerequisite for >>attendance. >> >>I assume this is what David was referring to regardless of the mail >>that was forwarded. >> >>Long live open protocols:-) >> >>beepy >> >>> Hi David, >>> >>> Just a clarification. >>> >>> The invitation sent out by Bill Lynn states that "This >event is open to >>all >>> IP Storage >>> > Forum members and there will be a nominal fee of $250.00 >per engineer >>> > attending. The current plan is to test to the iSCSI >draft standards >>> > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. > As this is a >>> > call >>> > for participation please respond with your company's intent to >>> > participate." >>> >>> Although opening the event to all may be a good idea, the >invitation did >>not >>> go that far. >>> >>> Regards, >>> Ahmad Zamer >>> Intel Corporation >>> voice: 512-407-2155 >>> mail: ahmad.zamer@intel.com >>> >>> >>> -----Original Message----- >>> From: Black_David@emc.com [mailto:Black_David@emc.com] >>> Sent: Monday, June 18, 2001 2:10 PM >>> To: ips@ece.cmu.edu >>> Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>> Participat ion >>> >>> >>> Since this topic has surfaced on this list, it is >>> my understanding that this plugfest is now open to >>> all participants, not just SNIA or UNH iSCSI consortium >>> members. >>> >>> FYI and thanks, >>> --David >>> >>> --------------------------------------------------- >>> David L. Black, Senior Technologist >>> EMC Corporation, 42 South St., Hopkinton, MA 01748 >>> +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 >>> black_david@emc.com Mobile: +1 (978) 394-7754 >>> --------------------------------------------------- >>> >>> >>> > -----Original Message----- >>> > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com] >>> > Sent: Monday, June 18, 2001 1:42 PM >>> > To: ips@ece.cmu.edu >>> > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>> > Participation >>> > >>> > >>> > >>> > Dear colleagues, >>> > >>> > I was asked by many of you what codes to use for the >plugfest. I think >>you >>> > would want to consider using the already published codes for 07 >>(published >>> > on this list) as an alternative to 06. The transition to >07 will be >>> > easier >>> > and you will >>> > have far less interoperability issues. >>> > >>> > Regards, >>> > Julo >>> > ---------------------- Forwarded by Julian Satran/Haifa/IBM on >>18-06-2001 >>> > 20:38 --------------------------- >>> > >>> > "Lynn, Bill" on 23-05-2001 19:37:42 >>> > >>> > Please respond to bill_lynn@btc.adaptec.com >>> > >>> > To: "'snia-ipsforum@snia.org'" >>> > cc: >>> > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>Participation >>> > >>> > >>> > >>> > >>> > IP Storage Forum Member >>> > >>> > The IP Storage Forum is pleased to announce the first IP >Storage Forum >>> > plugfest to be held on the 17th and 18th of July at the >University of >>New >>> > Hampshire's InterOperability Lab. This event is open to >all IP Storage >>> > Forum members and there will be a nominal fee of $250.00 >per engineer >>> > attending. The current plan is to test to the iSCSI >draft standards >>> > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. > As this is a >>> > call >>> > for participation please respond with your company's intent to >>> > participate. >>> > Information we would like to know is: >>> > >>> > Company Name >>> > Contact Name >(email and phone >>> > number) >>> > Number of >engineers attending >>> > Number and types >of products to >>be >>> > tested >>> > Protocol type and version >>> > implemented >>> > >>> > Logistical information should follow within the next two >weeks. The >>goal >>> > of >>> > the plugfest is to do some low level protocol testing >along with some >>> > higher >>> > level system testing. The information on types of products will >>determine >>> > the possible configurations we can construct. Please >email the above >>> > information to - >>> > >>> > >>> > bill_lynn@corp.adaptec.com >>> > >>> > If there are any questions please feel free to contact me at >>303-684-4706. >>> > >>> > >>> > Thanks >>> > >>> > >>> > Bill Lynn >>> > >>> > Secretary >>> > >>> > SNIA IP Storage Forum >>> > >>> > >>> > >>> > #### att1.htm has been deleted (was saved in repository >My Attachments >>> > Repository ->(Document link: Link to the attachment in >the repository)) >>> > from this note on 11 June 2001 by Julian Satran >>> > >>> > >>> >> >> > From owner-ips@ece.cmu.edu Wed Jun 20 19:29:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26339 for ; Wed, 20 Jun 2001 19:29:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KJK3T26442 for ips-outgoing; Wed, 20 Jun 2001 15:20:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5KJK2g26437 for ; Wed, 20 Jun 2001 15:20:02 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id TAA28357; Wed, 20 Jun 2001 19:19:42 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 20 Jun 2001 19:19:41 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 12:19:40 -0700 Message-ID: <9678C2B4D848D41187450090276D1FAE0AEFDB20@FMSMSX32> From: "Zamer, Ahmad" To: "'Barry Reinhold'" , "Zamer, Ahmad" , "'Brian Pawlowski'" Cc: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion Date: Wed, 20 Jun 2001 12:19:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Barry, I share your view. My remarks about "open fest" were in reply to the request that we open the first plugfest to all. Future events will require membership as that is what is dictated by common sense. Regards, Ahmad Zamer Intel Corporation voice: 512-407-2155 mail: ahmad.zamer@intl.com -----Original Message----- From: Barry Reinhold [mailto:bbrtrebia@mediaone.net] Sent: Wednesday, June 20, 2001 11:55 AM To: Zamer, Ahmad; 'Brian Pawlowski' Cc: Black_David@emc.com; ips@ece.cmu.edu Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion Having spent 10 years architecting and running the IOL I would like to note one thing. The issue about the "open" plugfest is really one of costs. Not the cost of the plugfest but of the iSCSI consortium itself. The iSCSI consortium essentially produces services and tools to improve iSCSI interoperability. The cost to cover this comes from membership fees in the iSCSI consortium. There is no profit in the IOL, so the flow of venture capitol dollars is pretty low. The issue for the IOL is how to fund the development. When the plugfest is "open" the number of companies that join the consortium is small, as there is no real reason to join it until it offers testing services (some development completes). This reduces the work being done towards the development of an open conformance test, and other interoperability tools and services -- dragging the process out longer. Having watched this process over the years from the inside I think we (the iSCSI community) are better off if we require membership. This way we all have a hard core reason to pay the membership fee in a timely manner. This will get us tools and interoperability testing services sooner. A compromise position might be to have membership required in the first plug fest but not in future ones. That way enough companies will get involved in the consortium that sufficient revenue is generated to ensure that the work moves forward but the overall process remains open. Future membership will be driven by the testing services that should then be in place. There are other approaches, but based on my past experience, requiring membership (and allowing some companies to request exceptions through UNH) is the best way to get this process moving. >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Zamer, Ahmad >Sent: Tuesday, June 19, 2001 7:06 AM >To: 'Brian Pawlowski'; Zamer, Ahmad >Cc: Black_David@emc.com; ips@ece.cmu.edu >Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >Participat ion > > >Hi, > >I recognize the overwhelming view that opening the plug fest to all is a >good idea and hereby reverse my previous position 180 degrees to be exact. >If so many people feel that an open event is good for all, then it better >be. > >Even I can see the light. > >I look forward to a successful plug fest next month. > >Ahmad Zamer >Intel Corporation >voice: 512-407-2155 >mail: ahmad.zamer@intel.com > >-----Original Message----- >From: Brian Pawlowski [mailto:beepy@netapp.com] >Sent: Monday, June 18, 2001 4:27 PM >To: ahmad.zamer@intel.com >Cc: Black_David@emc.com; ips@ece.cmu.edu >Subject: Re: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >Participat ion > > >The UNH site for the event: > > http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html > >dropped wording on requiring membership to any org as prerequisite for >attendance. > >I assume this is what David was referring to regardless of the mail >that was forwarded. > >Long live open protocols:-) > >beepy > >> Hi David, >> >> Just a clarification. >> >> The invitation sent out by Bill Lynn states that "This event is open to >all >> IP Storage >> > Forum members and there will be a nominal fee of $250.00 per engineer >> > attending. The current plan is to test to the iSCSI draft standards >> > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a >> > call >> > for participation please respond with your company's intent to >> > participate." >> >> Although opening the event to all may be a good idea, the invitation did >not >> go that far. >> >> Regards, >> Ahmad Zamer >> Intel Corporation >> voice: 512-407-2155 >> mail: ahmad.zamer@intel.com >> >> >> -----Original Message----- >> From: Black_David@emc.com [mailto:Black_David@emc.com] >> Sent: Monday, June 18, 2001 2:10 PM >> To: ips@ece.cmu.edu >> Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >> Participat ion >> >> >> Since this topic has surfaced on this list, it is >> my understanding that this plugfest is now open to >> all participants, not just SNIA or UNH iSCSI consortium >> members. >> >> FYI and thanks, >> --David >> >> --------------------------------------------------- >> David L. Black, Senior Technologist >> EMC Corporation, 42 South St., Hopkinton, MA 01748 >> +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 >> black_david@emc.com Mobile: +1 (978) 394-7754 >> --------------------------------------------------- >> >> >> > -----Original Message----- >> > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com] >> > Sent: Monday, June 18, 2001 1:42 PM >> > To: ips@ece.cmu.edu >> > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >> > Participation >> > >> > >> > >> > Dear colleagues, >> > >> > I was asked by many of you what codes to use for the plugfest. I think >you >> > would want to consider using the already published codes for 07 >(published >> > on this list) as an alternative to 06. The transition to 07 will be >> > easier >> > and you will >> > have far less interoperability issues. >> > >> > Regards, >> > Julo >> > ---------------------- Forwarded by Julian Satran/Haifa/IBM on >18-06-2001 >> > 20:38 --------------------------- >> > >> > "Lynn, Bill" on 23-05-2001 19:37:42 >> > >> > Please respond to bill_lynn@btc.adaptec.com >> > >> > To: "'snia-ipsforum@snia.org'" >> > cc: >> > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >Participation >> > >> > >> > >> > >> > IP Storage Forum Member >> > >> > The IP Storage Forum is pleased to announce the first IP Storage Forum >> > plugfest to be held on the 17th and 18th of July at the University of >New >> > Hampshire's InterOperability Lab. This event is open to all IP Storage >> > Forum members and there will be a nominal fee of $250.00 per engineer >> > attending. The current plan is to test to the iSCSI draft standards >> > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. As this is a >> > call >> > for participation please respond with your company's intent to >> > participate. >> > Information we would like to know is: >> > >> > Company Name >> > Contact Name (email and phone >> > number) >> > Number of engineers attending >> > Number and types of products to >be >> > tested >> > Protocol type and version >> > implemented >> > >> > Logistical information should follow within the next two weeks. The >goal >> > of >> > the plugfest is to do some low level protocol testing along with some >> > higher >> > level system testing. The information on types of products will >determine >> > the possible configurations we can construct. Please email the above >> > information to - >> > >> > >> > bill_lynn@corp.adaptec.com >> > >> > If there are any questions please feel free to contact me at >303-684-4706. >> > >> > >> > Thanks >> > >> > >> > Bill Lynn >> > >> > Secretary >> > >> > SNIA IP Storage Forum >> > >> > >> > >> > #### att1.htm has been deleted (was saved in repository My Attachments >> > Repository ->(Document link: Link to the attachment in the repository)) >> > from this note on 11 June 2001 by Julian Satran >> > >> > >> > > From owner-ips@ece.cmu.edu Wed Jun 20 19:29:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26349 for ; Wed, 20 Jun 2001 19:29:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5KJNa026704 for ips-outgoing; Wed, 20 Jun 2001 15:23:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5KJNYg26699 for ; Wed, 20 Jun 2001 15:23:34 -0400 (EDT) Received: from breinhold ([140.186.66.73]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f5KJN1611885; Wed, 20 Jun 2001 15:23:08 -0400 (EDT) From: "Barry Reinhold" To: "Dennis Young" , "Zamer, Ahmad" , "'Brian Pawlowski'" Cc: , Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for Participat ion Date: Wed, 20 Jun 2001 15:19:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <45BEF1D68145D51186C100B0D0AABE6506CE96@med.corp.rhapsodynetworks.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This idea has been discussed a number of times for a number of different technologies. There are some issues (both operational and security) that need to be worked out but I believe it can be made to work. I propose that we have a round table on this one at the plugfest. >-----Original Message----- >From: Dennis Young [mailto:dyoung@rhapsodynetworks.com] >Sent: Wednesday, June 20, 2001 3:06 PM >To: 'Barry Reinhold'; Zamer, Ahmad; 'Brian Pawlowski' >Cc: Black_David@emc.com; ips@ece.cmu.edu >Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >Participat ion > > >Is there any thought about making a longer term interoperability >test setup >on the Internet (make it private using VPN if security is a concern). >Companies that build iSCSI switches can connect their gears to >this network >from their own facilities, same for storage device and HBA vendors. >The current IOL or other organizations can manage the network and >operation >policy such as scheduling, addition and removal of equipments, etc. >This is not my idea, just something I overheard in a storage conference. >-dennis > >>-----Original Message----- >>From: Barry Reinhold [mailto:bbrtrebia@mediaone.net] >>Sent: Wednesday, June 20, 2001 9:55 AM >>To: Zamer, Ahmad; 'Brian Pawlowski' >>Cc: Black_David@emc.com; ips@ece.cmu.edu >>Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>Participat ion >> >> >>Having spent 10 years architecting and running the IOL I would >>like to note >>one thing. The issue about the "open" plugfest is really one >>of costs. Not >>the cost of the plugfest but of the iSCSI consortium itself. The iSCSI >>consortium essentially produces services and tools to improve iSCSI >>interoperability. The cost to cover this comes from membership >>fees in the >>iSCSI consortium. There is no profit in the IOL, so the flow of venture >>capitol dollars is pretty low. The issue for the IOL is how to fund the >>development. >>When the plugfest is "open" the number of companies that join >>the consortium >>is small, as there is no real reason to join it until it offers testing >>services (some development completes). This reduces the work being done >>towards the development of an open conformance test, and other >>interoperability tools and services -- dragging the process out longer. >>Having watched this process over the years from the inside I >>think we (the >>iSCSI community) are better off if we require membership. This >>way we all >>have a hard core reason to pay the membership fee in a timely >>manner. This >>will get us tools and interoperability testing services sooner. >>A compromise position might be to have membership required in >>the first plug >>fest but not in future ones. That way enough companies will >>get involved in >>the consortium that sufficient revenue is generated to ensure >>that the work >>moves forward but the overall process remains open. Future >>membership will >>be driven by the testing services that should then be in place. >>There are other approaches, but based on my past experience, requiring >>membership (and allowing some companies to request exceptions >>through UNH) >>is the best way to get this process moving. >> >>>-----Original Message----- >>>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >>>Zamer, Ahmad >>>Sent: Tuesday, June 19, 2001 7:06 AM >>>To: 'Brian Pawlowski'; Zamer, Ahmad >>>Cc: Black_David@emc.com; ips@ece.cmu.edu >>>Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>>Participat ion >>> >>> >>>Hi, >>> >>>I recognize the overwhelming view that opening the plug fest >>to all is a >>>good idea and hereby reverse my previous position 180 degrees >>to be exact. >>>If so many people feel that an open event is good for all, >>then it better >>>be. >>> >>>Even I can see the light. >>> >>>I look forward to a successful plug fest next month. >>> >>>Ahmad Zamer >>>Intel Corporation >>>voice: 512-407-2155 >>>mail: ahmad.zamer@intel.com >>> >>>-----Original Message----- >>>From: Brian Pawlowski [mailto:beepy@netapp.com] >>>Sent: Monday, June 18, 2001 4:27 PM >>>To: ahmad.zamer@intel.com >>>Cc: Black_David@emc.com; ips@ece.cmu.edu >>>Subject: Re: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>>Participat ion >>> >>> >>>The UNH site for the event: >>> >>> http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html >>> >>>dropped wording on requiring membership to any org as prerequisite for >>>attendance. >>> >>>I assume this is what David was referring to regardless of the mail >>>that was forwarded. >>> >>>Long live open protocols:-) >>> >>>beepy >>> >>>> Hi David, >>>> >>>> Just a clarification. >>>> >>>> The invitation sent out by Bill Lynn states that "This >>event is open to >>>all >>>> IP Storage >>>> > Forum members and there will be a nominal fee of $250.00 >>per engineer >>>> > attending. The current plan is to test to the iSCSI >>draft standards >>>> > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. >> As this is a >>>> > call >>>> > for participation please respond with your company's intent to >>>> > participate." >>>> >>>> Although opening the event to all may be a good idea, the >>invitation did >>>not >>>> go that far. >>>> >>>> Regards, >>>> Ahmad Zamer >>>> Intel Corporation >>>> voice: 512-407-2155 >>>> mail: ahmad.zamer@intel.com >>>> >>>> >>>> -----Original Message----- >>>> From: Black_David@emc.com [mailto:Black_David@emc.com] >>>> Sent: Monday, June 18, 2001 2:10 PM >>>> To: ips@ece.cmu.edu >>>> Subject: RE: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>>> Participat ion >>>> >>>> >>>> Since this topic has surfaced on this list, it is >>>> my understanding that this plugfest is now open to >>>> all participants, not just SNIA or UNH iSCSI consortium >>>> members. >>>> >>>> FYI and thanks, >>>> --David >>>> >>>> --------------------------------------------------- >>>> David L. Black, Senior Technologist >>>> EMC Corporation, 42 South St., Hopkinton, MA 01748 >>>> +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 >>>> black_david@emc.com Mobile: +1 (978) 394-7754 >>>> --------------------------------------------------- >>>> >>>> >>>> > -----Original Message----- >>>> > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com] >>>> > Sent: Monday, June 18, 2001 1:42 PM >>>> > To: ips@ece.cmu.edu >>>> > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>>> > Participation >>>> > >>>> > >>>> > >>>> > Dear colleagues, >>>> > >>>> > I was asked by many of you what codes to use for the >>plugfest. I think >>>you >>>> > would want to consider using the already published codes for 07 >>>(published >>>> > on this list) as an alternative to 06. The transition to >>07 will be >>>> > easier >>>> > and you will >>>> > have far less interoperability issues. >>>> > >>>> > Regards, >>>> > Julo >>>> > ---------------------- Forwarded by Julian Satran/Haifa/IBM on >>>18-06-2001 >>>> > 20:38 --------------------------- >>>> > >>>> > "Lynn, Bill" on 23-05-2001 19:37:42 >>>> > >>>> > Please respond to bill_lynn@btc.adaptec.com >>>> > >>>> > To: "'snia-ipsforum@snia.org'" >>>> > cc: >>>> > Subject: SNIA-IPSFORUM: IP Storage Forum Plugfest, Call for >>>Participation >>>> > >>>> > >>>> > >>>> > >>>> > IP Storage Forum Member >>>> > >>>> > The IP Storage Forum is pleased to announce the first IP >>Storage Forum >>>> > plugfest to be held on the 17th and 18th of July at the >>University of >>>New >>>> > Hampshire's InterOperability Lab. This event is open to >>all IP Storage >>>> > Forum members and there will be a nominal fee of $250.00 >>per engineer >>>> > attending. The current plan is to test to the iSCSI >>draft standards >>>> > versions 0.0 and 0.6. Versions of FCIP and iFCP are TBD. >> As this is a >>>> > call >>>> > for participation please respond with your company's intent to >>>> > participate. >>>> > Information we would like to know is: >>>> > >>>> > Company Name >>>> > Contact Name >>(email and phone >>>> > number) >>>> > Number of >>engineers attending >>>> > Number and types >>of products to >>>be >>>> > tested >>>> > Protocol type and version >>>> > implemented >>>> > >>>> > Logistical information should follow within the next two >>weeks. The >>>goal >>>> > of >>>> > the plugfest is to do some low level protocol testing >>along with some >>>> > higher >>>> > level system testing. The information on types of products will >>>determine >>>> > the possible configurations we can construct. Please >>email the above >>>> > information to - >>>> > >>>> > >>>> > bill_lynn@corp.adaptec.com >>>> > >>>> > If there are any questions please feel free to contact me at >>>303-684-4706. >>>> > >>>> > >>>> > Thanks >>>> > >>>> > >>>> > Bill Lynn >>>> > >>>> > Secretary >>>> > >>>> > SNIA IP Storage Forum >>>> > >>>> > >>>> > >>>> > #### att1.htm has been deleted (was saved in repository >>My Attachments >>>> > Repository ->(Document link: Link to the attachment in >>the repository)) >>>> > from this note on 11 June 2001 by Julian Satran >>>> > >>>> > >>>> >>> >>> >> From owner-ips@ece.cmu.edu Wed Jun 20 22:26:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29581 for ; Wed, 20 Jun 2001 22:26:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5L0Op018049 for ips-outgoing; Wed, 20 Jun 2001 20:24:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5L0Oog18044 for ; Wed, 20 Jun 2001 20:24:50 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 20:24:44 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E07091C@corpmx14.us.dg.com> From: Black_David@emc.com To: mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Wed, 20 Jun 2001 20:21:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Since this seems to need a consensus call, I believe the WG consensus on SendTargets for iSCSI is: - Retain the functionality, document it in the main portion of the specification. - SendTargets will not return Aliases or Certificates. This is part of limiting its functionality to basic description of the iSCSI device to which it is attached. - Add an argument to Send Targets to enable it to perform what has previously been called Report Portal Groups. When the target name is present (even the canonical "iscsi" target), the result is to return portal information. Reviewing the mail thread since Mark's initial message with the above subject line: - Doug Otis's objections appear to be to iSNS and not to the above proposed SendTargets consensus. - The proposed consensus to document SendTargets in the main part of the specification takes note of and hence overrides Larry Lamers's preference for documenting in an Annex. Anyone who disagrees with the above statement of consensus should post to the list. There's one issue that's not completely clear to me from the discussion, and that is how to limit the scope of information that is returned by SendTargets to match what I believe to be the sense of the discussion that SendTargets's purpose is to describe the device/implementation/instance to which it is issued. I can see a couple of choices: (A) SendTargets only returns information about targets that are accessible through the to which the SendTargets was issued. (B) SendTargets only returns information about targets that are accessible through an that can also access the *same* canonical iSCSI target instance to which the SendTargets was issued. (A) is the simpler one to explain and understand, and may do a better job of structuring the discovery process (new iSCSI "instances" can't be discovered as a result of issuing SendTargets) at the price of potentially having to discover more iSCSI communication endpoints to which SendTargets has to be issued at the earlier stage of discovery. (B) allows configuration to be centralized in some cases where (A) does not, but the notion of "*same* canonical iSCSI target instance" strikes me as hard to define and enforce in a protocol spec, and opens SendTargets up to virtualization of the canonical target (e.g., by replication of state information) in a fashion that could turn SendTargets into a network-wide discovery mechanism, which seems contrary to the sense of the discussion. (A) seems to be the choice that better fits what I believe the sense of the discussion is. Comments? Thanks, --David > -----Original Message----- > From: Mark Bakke [SMTP:mbakke@cisco.com] > Sent: Wednesday, June 20, 2001 10:02 AM > To: John Hufferd > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Wrapping up SendTargets > > > This thread turned out more interesting than I had expected, > but anyway, after reading through the messages sent while I > was gone, it looks like we at least have some consensus on > keeping SendTargets. > > I would like to see John's option #2 as well. Currently, > SendTargets is documented in the naming & discovery document; > where should we put it in the iSCSI spec? > > We will also need to close on some of the previous threads > about aggregation tags, iteration, etc. > > It looks like we should continue the thread on the future > (SLP, iSNS, etc.) discovery stuff, but I should have started > that one separately. > > -- > Mark > > John Hufferd wrote: > > > > iSCSI Team, > > I think that Jim has said it well. I had a proposal about an Annex, for > > the SendTargets, but whether we do that or not, I am getting the feeling > > that most folks think, at least for this version of the protocol that we > > keep SendTargets, and the subset that can be used as a Report Portal > > Groups. Even Mark, even though he thought he could Hack the SLP Source > > code to do a similar thing, thought that it was best to keep > SendTargets. > > > > I would like to propose that we Close on Keeping the SendTargets > command, > > and the subset that is either Report Portal Groups or SendTargets > Target Name> (which returns only the information for that target only). > > > > Now as to where we put the command. I suggested an Annex, but can > clearly > > live with it in the Main document. I seemed to get very little support > for > > the idea of the Annex, and since I think that the functions of Report > > Portal Groups, must be part of the base, I would like to suggest that > we > > either > > 1) Place the SendTargets in the Annex, and put a Report Portal Groups in > > the main document, or > > 2) Keep the Send Targets in the Main Document and add the argument of > > > > > > Please state your positions > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Internet address: hufferd@us.ibm.com > > > > Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 06/12/2001 04:56:10 PM > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: ips@ece.cmu.edu > > cc: > > Subject: RE: iSCSI: Wrapping up SendTargets > > > > Folks, > > > > I think this thread is wandering off the field. > > > > The question is the issue of SendTargets. Let's remind ourselves of the > > original purpose of this proposed protocol: namely, it's designed for a > > storage box that contains one or more iSCSI target devices to report > about > > ITSELF, about what's in it! This includes both a list of the iSCSI > targets > > it has PLUS the session coordination (via tags) of the various > > IPaddress/tcpport combos it supports. > > > > In other words, it's job is to report about itself! The use of > (unicast) > > SLP as an alternative to SendTargets was focused exactly on the same > > question: I ask a single box to tell me about itself. This function > lies > > between the two extremes of (a) static configuration of initiators and > (b) > > centralized management via iSNS style services. > > > > Somehow, someway, we need to define a protocol for a box to "tell us > about > > itself" in the absense of the centralized management infrastructure. > That > > seems critical to me. Even if I want to do static configuration, the > guy > > doing the configuration needs a way to get at the guts of each new box > > he/she rolls into the environment. > > > > The choices are, it seems, that *every* box would need to support at > least > > one of: > > a) SendTargets > > b) modified SLP > > c) iSNS > > > > What's the consensus on the protocol we aim for to solve this middle > ground > > discovery problem? > > Jim Hafner > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Thu Jun 21 00:02:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03556 for ; Thu, 21 Jun 2001 00:02:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5L23EB24254 for ips-outgoing; Wed, 20 Jun 2001 22:03:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5L23Dg24249 for ; Wed, 20 Jun 2001 22:03:13 -0400 (EDT) Received: (cpmta 12999 invoked from network); 20 Jun 2001 19:03:06 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.206) with SMTP; 20 Jun 2001 19:03:06 -0700 X-Sent: 21 Jun 2001 02:03:06 GMT From: "Douglas Otis" To: "Tsvwg" , "Ips" Subject: CRC-32c Algorithm checking D'oh Date: Wed, 20 Jun 2001 19:00:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, I have made an error in the CRC algorithm presented in the SCTP digest draft. The reflected table returns a value that has MS and LS bytes reflected in addition to the bits within a byte. The error was my placement of the results. There is an example code that implements both the table methods and a bit by bit method for comparison. Here is the results with a test pattern of "123456789". Table CRC results: Normalized =C14960C7 Reflected =E3069283 Table CRC check: Normalized =FFFFFFFF Reflected =FFFFFFFF Bit CRC results: Normal =C14960C7 Doug #define polynomial 0x1EDC6F41L /* generated using (0x11EDC6F41) x^32+x^28+x^27+x^26+x^25+x^23+x^22+x^20+x^19+x^18+x^14+x^13+ x^11+x^10+x^9+x^8+x^6+1 */ unsigned long crctab[256] = { 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L }; #define CRC32(crc, d) (crc=(crc>>8)^crctab[(crc^(d))&0xff]) unsigned char testbuf[] = { 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x00, 0x00, 0x00, 0x00, }; unsigned int rb (unsigned int r) { int i; unsigned int n = r; for (i = 0; i < 8; i++) { if (n & 1) r |= 1 << (7 - i); else r &= ~(1 << (7 - i)); n >>= 1; } return r; } /* fscgen generates the digest based on Digest Designator */ /* buf[] contains the SCTP packet */ /* length is the packet length including padding */ unsigned int tablegen (unsigned char buf[], int length) { int i = 0; unsigned int crc = ~0; while (i < length) { CRC32 (crc, buf[i++]); /* assumes digest zeroed */ } crc ^= ~0; return (crc); } unsigned int bitgen (unsigned char buf[], int length) { int i = 0; int j; unsigned char d; unsigned int crc = ~0; while (i < length) { d = buf[i++]; for (j = 0; j < 8; j++) { if ((crc >> 31) ^ (d & 1)) { crc = (crc << 1) ^ polynomial; } else { crc <<= 1; } d >>= 1; } } crc ^= ~0; return (crc); } main () { unsigned int val; val = tablegen (testbuf, 9); printf ("Table CRC results: Normalized =%02X%02X%02X%02X Reflected =%X\n", rb (val & 0xff), rb ((val >> 8) & 0xff), rb ((val >> 16) & 0xff), rb (val >> 24), val); val ^= ~0; testbuf[9] = val & 0xff; testbuf[10] = (val >> 8) & 0xff; testbuf[11] = (val >> 16) & 0xff; testbuf[12] = (val >> 24) & 0xff; val = tablegen (testbuf, 13); printf ("Table CRC check: Normalized =%02X%02X%02X%02X Reflected =%X\n", rb (val & 0xff), rb ((val >> 8) & 0xff), rb ((val >> 16) & 0xff), rb (val >> 24), val); val = bitgen (testbuf, 9); printf ("Bit CRC results: Normal =%X\n", val); } From owner-ips@ece.cmu.edu Thu Jun 21 15:11:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14565 for ; Thu, 21 Jun 2001 15:11:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5LH8YF01536 for ips-outgoing; Thu, 21 Jun 2001 13:08:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com (sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5LH8Wg01523 for ; Thu, 21 Jun 2001 13:08:32 -0400 (EDT) Received: from cs.uchicago.edu (dynamite-4.sandburst.com [172.16.5.4]) by sandmail.sandburst.com (Postfix) with ESMTP id 59EC34E8B for ; Thu, 21 Jun 2001 13:08:31 -0400 (EDT) To: ips@ece.cmu.edu Subject: Re: iSCSI:Text field in Asynchronous Message In-Reply-To: Message from "Elliott, Robert" of "Thu, 21 Jun 2001 00:15:15 CDT." <78AF3C342AEAEF4BA33B35A8A15668C6014D675A@cceexc17.americas.cpqcorp.net> References: <78AF3C342AEAEF4BA33B35A8A15668C6014D675A@cceexc17.americas.cpqcorp.net> Date: Thu, 21 Jun 2001 13:08:23 -0400 From: Stephen Bailey Message-Id: <20010621170831.59EC34E8B@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk > Both iSCSI and SRP have native Asynchronous Event Reporting IUs which can be > used for this type of purpose. I guess my point is that FCP doesn't, and it's the only currently deployed SAN solution. Beyond that, some SCSI stacks (Solaris, unless they've changed something recently....), don't provide support for clients to receive SCSI AENs. In other words, the useful support for SCSI AEN is patchy. I'm not arguing that AEN support shouldn't be provided by a transport. I am arguing that if you want your (target) solution to work on many platforms and transports, you might chose not to use AEN. Prominent target vendors (e.g. LSI/Symbios) have taken this route. Steph From owner-ips@ece.cmu.edu Thu Jun 21 15:13:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14696 for ; Thu, 21 Jun 2001 15:13:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5LHPBH02719 for ips-outgoing; Thu, 21 Jun 2001 13:25:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5LH93g01565 for ; Thu, 21 Jun 2001 13:09:03 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id TAA56866 for ; Thu, 21 Jun 2001 19:08:56 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5LH8tN24716 for ; Thu, 21 Jun 2001 19:08:55 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A72.005E083A ; Thu, 21 Jun 2001 19:07:04 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Thu, 21 Jun 2001 20:14:39 +0300 Subject: profiles - a way to simplify iSCSI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, iSCSI keeps getting richer in negotiable parameters/features. Although flexibility is a great thing every new negotiable parameter/feature get us all worrying about: what it will break when used in combination with other parameters/features how are we going to test that all our combinations work as we think that they are specified are we understanding/specifying the combinations the same way as anybody else I assume that many of you are wondering, as I do, if all this flexibility is really worth it's price. Would the community not be better served by specifying profiles that are a complete-and-invariable combination of features and very small set of numerical parameters? I would start with 2 profiles: the minimal profile (only basic features) the maximum profile (all the features) and then (only if we are strongly convinced it is needed) add a middle point. Please comment, Julo From owner-ips@ece.cmu.edu Thu Jun 21 15:14:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14770 for ; Thu, 21 Jun 2001 15:14:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5LIKK406957 for ips-outgoing; Thu, 21 Jun 2001 14:20:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5LIKIg06953 for ; Thu, 21 Jun 2001 14:20:18 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Thu Jun 21 14:19:10 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Thu Jun 21 14:19:57 EDT 2001 Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id OAA24609; Thu, 21 Jun 2001 14:19:21 -0400 (EDT) Message-ID: <3B323AA9.62699F3@research.bell-labs.com> Date: Thu, 21 Jun 2001 14:19:21 -0400 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: julian_satran@il.ibm.com CC: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hmm..this is somewhat tempting.  The parameters seem to fall into 2-3 clusters (1) initialR2T, maxR2T, immediate data, firstburst, pdulength, etc (2) the marker related keys (3) names, aliases, bootsession, maxconnections, loginlogout min-max. It would be nice if a "profile" could simplify these dependencies. Under this proposed setup, I presume the target & initiator would first send a profile-name which would initialize the appropriate parameters in the set. If a vendor is unsure of a particular profile, support for it would not be advertised. Once a profile is decided, only numeric keys would be negotiated. Could you elaborate further on your proposal ? -Sandeep julian_satran@il.ibm.com wrote: > > Dear colleagues, > > iSCSI keeps getting richer in negotiable parameters/features. > Although flexibility is a great thing every new negotiable > parameter/feature get us all worrying about: > > what it will break when used in combination with other > parameters/features > how are we going to test that all our combinations work as we think that > they are specified > are we understanding/specifying the combinations the same way as anybody > else > > I assume that many of you are wondering, as I do, if all this flexibility > is really worth it's price. > Would the community not be better served by specifying profiles that are a > complete-and-invariable combination of features and very small set of > numerical parameters? > > I would start with 2 profiles: > > the minimal profile (only basic features) > the maximum profile (all the features) > > and then (only if we are strongly convinced it is needed) add a middle > point. > > Please comment, > Julo From owner-ips@ece.cmu.edu Thu Jun 21 15:15:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14812 for ; Thu, 21 Jun 2001 15:15:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5LIFCL06572 for ips-outgoing; Thu, 21 Jun 2001 14:15:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from OPUS.PDL.CMU.EDU (root@OPUS.PDL.CMU.EDU [128.2.134.91]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5LIFAg06564 for ; Thu, 21 Jun 2001 14:15:10 -0400 (EDT) Received: from opus.pdl.cmu.edu (bassoon@localhost [127.0.0.1]) by OPUS.PDL.CMU.EDU (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA23663 for ; Thu, 21 Jun 2001 14:15:10 -0400 Message-Id: <200106211815.OAA23663@OPUS.PDL.CMU.EDU> To: ips@ece.cmu.edu Subject: ips mailing list archive Date: Thu, 21 Jun 2001 14:15:10 -0400 From: Dave Nagle Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi everyone, The ips mailing list archive has moved to: http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html The old one will probably be up for few more days ... From owner-ips@ece.cmu.edu Thu Jun 21 15:16:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14825 for ; Thu, 21 Jun 2001 15:16:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5LHpog04760 for ips-outgoing; Thu, 21 Jun 2001 13:51:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [192.151.10.58]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5LHpmg04749 for ; Thu, 21 Jun 2001 13:51:48 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 216F51F792 for ; Thu, 21 Jun 2001 10:51:42 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA25712 for ; Thu, 21 Jun 2001 10:51:36 -0700 (PDT) Message-ID: <3B32348E.3F49EC47@cup.hp.com> Date: Thu, 21 Jun 2001 10:53:18 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI References: Content-Type: multipart/mixed; boundary="------------D44A6D27971F9DEAF64B79EA" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------D44A6D27971F9DEAF64B79EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, I am in favor of developing an iSCSI profile document along the lines of FC-PLDA and FC-FLA. This will go a long way in ensuring smoother interoperability. I had suggested over 4 months ago, that such a profile of features is useful for iSCSI and should be specified. (ex : http://ips.pdl.cs.cmu.edu/mail/msg03276.html). I'm not certain on what one gains by having 2 profiles. Basically, a profile should only state the requirement for each feature as one of : R - required P - Prohibited A - Allowed I - Invokable The mandatory (R) features of the profile constitute the minimal protocol conformance required. Implementation of the Allowed/Invokable (A, I) features constitues maximal conformance to the protocol. There should not be a need for 2 profile documents (?). Regards, Santosh julian_satran@il.ibm.com wrote: > > Dear colleagues, > > iSCSI keeps getting richer in negotiable parameters/features. > Although flexibility is a great thing every new negotiable > parameter/feature get us all worrying about: > > what it will break when used in combination with other > parameters/features > how are we going to test that all our combinations work as we think that > they are specified > are we understanding/specifying the combinations the same way as anybody > else > > I assume that many of you are wondering, as I do, if all this flexibility > is really worth it's price. > Would the community not be better served by specifying profiles that are a > complete-and-invariable combination of features and very small set of > numerical parameters? > > I would start with 2 profiles: > > the minimal profile (only basic features) > the maximum profile (all the features) > > and then (only if we are strongly convinced it is needed) add a middle > point. > > Please comment, > Julo --------------D44A6D27971F9DEAF64B79EA Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------D44A6D27971F9DEAF64B79EA-- From owner-ips@ece.cmu.edu Thu Jun 21 17:05:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17820 for ; Thu, 21 Jun 2001 17:05:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5LJIBT11397 for ips-outgoing; Thu, 21 Jun 2001 15:18:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from aegis.indstorage.com (www.diigroup.com [208.132.17.2] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5LJI9g11392 for ; Thu, 21 Jun 2001 15:18:10 -0400 (EDT) Received: from aegis (markb.indstorage.com [192.168.1.66]) by aegis.indstorage.com (8.11.0/8.11.0) with SMTP id f5LJEmi06990; Thu, 21 Jun 2001 13:14:48 -0600 From: "Mark Bradley" To: , Subject: RE: profiles - a way to simplify iSCSI Date: Thu, 21 Jun 2001 12:54:59 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is a very slipery slope. 'Required to be implemented' means that you must support to be compliant to a specification. 'Flavors' of implementation to anything other than required sounds like a marketing playground more than a means of ensuring interoperability. -- markb > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Thursday, June 21, 2001 11:15 AM > To: ips@ece.cmu.edu > Subject: profiles - a way to simplify iSCSI > > > > > Dear colleagues, > > iSCSI keeps getting richer in negotiable parameters/features. > Although flexibility is a great thing every new negotiable > parameter/feature get us all worrying about: > > what it will break when used in combination with other > parameters/features > how are we going to test that all our combinations work as we > think that > they are specified > are we understanding/specifying the combinations the same way > as anybody > else > > > I assume that many of you are wondering, as I do, if all this flexibility > is really worth it's price. > Would the community not be better served by specifying profiles that are a > complete-and-invariable combination of features and very small set of > numerical parameters? > > I would start with 2 profiles: > > the minimal profile (only basic features) > the maximum profile (all the features) > > and then (only if we are strongly convinced it is needed) add a middle > point. > > Please comment, > Julo > > From owner-ips@ece.cmu.edu Thu Jun 21 17:09:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17906 for ; Thu, 21 Jun 2001 17:09:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5LJ7mw10511 for ips-outgoing; Thu, 21 Jun 2001 15:07:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5LJ7lg10507 for ; Thu, 21 Jun 2001 15:07:47 -0400 (EDT) Received: from sdsl-216-36-75-164.dsl.sjc.megapath.net (HELO somesh) (216.36.75.164) by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Jun 2001 19:07:46 -0000 X-Apparently-From: Reply-To: From: "Somesh Gupta" To: , Subject: RE: profiles - a way to simplify iSCSI Date: Thu, 21 Jun 2001 11:59:09 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think this is indicative of the complexity we have in the standard. The first order of preference should be to reduce the complexity. Secondly, given the confusing decision process in the IETF, it is not certain whether we would meet the following two goals that I would have 1. Speedy process. 2. A large community of vendors and customers agreeing on an ideal profile that would be implemented widely. (of course, that means that everything else in the spec would be relegated to the position where 5 yrs from now only few will be able to explain why it is in the spec) Otherwise profiles are just going to add another dimension to negotiate without providing much benefit. Unless you say that profiles completely eliminate parameter negotiation (then it does add a lot of value). Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Thursday, June 21, 2001 10:15 AM > To: ips@ece.cmu.edu > Subject: profiles - a way to simplify iSCSI > > > > > Dear colleagues, > > iSCSI keeps getting richer in negotiable parameters/features. > Although flexibility is a great thing every new negotiable > parameter/feature get us all worrying about: > > what it will break when used in combination with other > parameters/features > how are we going to test that all our combinations work as we > think that > they are specified > are we understanding/specifying the combinations the same way > as anybody > else > > > I assume that many of you are wondering, as I do, if all this flexibility > is really worth it's price. > Would the community not be better served by specifying profiles that are a > complete-and-invariable combination of features and very small set of > numerical parameters? > > I would start with 2 profiles: > > the minimal profile (only basic features) > the maximum profile (all the features) > > and then (only if we are strongly convinced it is needed) add a middle > point. > > Please comment, > Julo > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ips@ece.cmu.edu Thu Jun 21 19:18:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20075 for ; Thu, 21 Jun 2001 19:18:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5LLHvG20535 for ips-outgoing; Thu, 21 Jun 2001 17:17:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5LLHtg20530 for ; Thu, 21 Jun 2001 17:17:55 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 14:17:48 -0700 Message-ID: From: Charles Monia To: "'ENDL_TX@computer.org'" Cc: "Ips (E-mail)" Subject: RE: Common Encapsulation: Stale Frame Detection in an IP fabric Date: Thu, 21 Jun 2001 14:17:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Ralph: Thanks for the feedback. I agree with your comments on the straw man. I will prepare an individual submittal proposing the exact textual changes to the common encapsulation spec. Charles > -----Original Message----- > From: Ralph Weber [mailto:ralphoweber@compuserve.com] > Sent: Tuesday, June 12, 2001 6:23 PM > To: Ips (E-mail) > Cc: Charles Monia > Subject: Re: Common Encapsulation: Stale Frame Detection in > an IP fabric > > > Charles, > > Sorry to take so long responding, only now am I catching > up on the complex issues. > > First, I would have to answer "yes" to the following > question from David Black: > > "Is there any interest in just synchronizing the > timestamps between the two ends of an FCIP link > without requiring interaction with an external > time source?" > > Such a capability would be very useful to FCIP implementations > where the IP Network lacks an SNTP server. > > David raises the further question: > > "A possible downside is that an implementation > that can support multiple FCIP links may need > to maintain a separate time offset (from its > internal time source) for each FCIP link." > > I see this "downside" as a fact of life requirement > since the FCIP device has no way of knowing if the > time offset is identical for two links. At a minimum > the FCIP device would have to interrogate each link > to verify its time offset. Having gone to that much > trouble, I see no reason why the discovered values > would not be maintained separately. > > >From my perspective, the downside issues for David's > proposal are as follows: > > 1) The common encapsulation draft will need to > recognize the two mechanisms for handling > time. Since a common flag bit has already > been proposed for "time valid" the simplest > method for recognizing both time mechanisms > would be to have one "valid flag" bit for > each. > > 2) It seems likely that an efficient implementation > of David's proposal would not use the SNTP time > format. This possibility would have to be dealt > with in the common encapsulation draft. > > 3) The mechanism non-SNTP-server mechanism for > determining the offset time would have to be > specified somewhere. Past implementations > have used FC frames for this purpose, and > that suggests that the mechanism would not > be specified in the common encapsulation draft. > > However, I can imagine trying to shoe-horn > such a capability in to common encapsulation > header. I think it is a bad idea since a > possible result is common encapsulation > headers that do not encapsulate FC frames. > But maybe I have missed something here. > > Despite these downside issue, I still think a one-link > end-to-end time stamp is a good idea. Anybody else agree? > > > Turning to Charles' 23 May proposal I think it is > generally complete and could be added to the common > encapsulation draft without too much trouble. My > concerns are as follows: > > 11) I am not certain exactly what parts of the > proposal are intended to go in the common > encapsulation draft or where they are > intended to go. > > 12) I do not understand the purpose of the text > near the end of the proposal, beginning with > "Setting the enforcement time limit." It seems > to me that the encapsulation element should be > told exactly one upper limit value for the > IP Network transit time of an encapsulated frame. > This time limit should be provided by the > 'Fibre Channel' component of which the > encapsulation element is a part. For example, > an FC Switch would set a time limit based on > its determination of how R_A_TOV is to be > divided for a given FC Fabric routing. > I believe the discussion of E_D_TOV and > R_A_TOV should not be included in the > common encapsulation draft. > > 13) I believe that the following needs to be reworded: > > "d) If the incoming frame has a non-zero time stamp, > the receiving node shall compute the time in flight > and compare it against the limit specified for the IP > fabric." > > I think it would be better to drop the "IP fabric" > since that term is specific to only one of the > users of the common encapsulation. I also would > prefer not to have "receiving node" in the wording > because that concept has no definition in the > common encapsulation draft. I would suggest: > > "d) If an encapsulation header contains a non zero > value in the Time Stamp [integer] field, the time > in flight SHALL be computed by subtracting the > reference time from the Time Stamp [integer] and > Time Stamp [fraction] fields." > > Quite probably similar wording changes are needed elsewhere > in the proposal. > > Thanks. > > Ralph... > From owner-ips@ece.cmu.edu Thu Jun 21 21:40:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24420 for ; Thu, 21 Jun 2001 21:40:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5LNQUM29550 for ips-outgoing; Thu, 21 Jun 2001 19:26:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [128.221.10.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5LNQTg29545 for ; Thu, 21 Jun 2001 19:26:29 -0400 (EDT) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 19:26:23 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070926@corpmx14.us.dg.com> From: Black_David@emc.com To: julian_satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: profiles - a way to simplify iSCSI Date: Thu, 21 Jun 2001 19:23:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > iSCSI keeps getting richer in negotiable parameters/features. > Although flexibility is a great thing every new negotiable > parameter/feature get us all worrying about: > > what it will break when used in combination with other > parameters/features > how are we going to test that all our combinations work as we think that > they are specified > are we understanding/specifying the combinations the same way as anybody > else All worthy questions, but I think one important one is left out - Why does iSCSI have so many negotiable parameters/features? This leads into ... > I assume that many of you are wondering, as I do, if all this flexibility > is really worth it's price. If it leads to implementations that fail to interoperate, the answer is "no". > Would the community not be better served by specifying profiles that are a > complete-and-invariable combination of features and very small set of > numerical parameters? I think it's incumbent on the WG to reduce the amount of flexibility by removing things and restricting implementation flexibility (e.g., specifying that for a certain set of features implementations MUST support all of the features in the set if they support any one of them). This belongs in the main body of the specification, not a separate profile. See RFC 2119 for the appropriate terms to use in specifying requirements for implementations. IMHO, if a specification requires profiles in order to obtain interoperable implementations, then the specification itself is insufficiently precise and needs to be tightened in order to merit approval as a proposed standard RFC. It's time to start thinking about what we can take out ... Writing as an IPS WG co-chair, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jun 21 23:26:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26818 for ; Thu, 21 Jun 2001 23:26:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5M14Fv05563 for ips-outgoing; Thu, 21 Jun 2001 21:04:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5M14Eg05559 for ; Thu, 21 Jun 2001 21:04:14 -0400 (EDT) Received: from cs.uchicago.edu ([24.91.87.148]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f5M14Dx08368 for ; Thu, 21 Jun 2001 21:04:13 -0400 (EDT) Message-Id: <200106220104.f5M14Dx08368@chmls05.mediaone.net> To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI In-Reply-To: Message from "Somesh Gupta" of "Thu, 21 Jun 2001 11:59:09 PDT." References: Date: Thu, 21 Jun 2001 21:04:04 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk > I think this is indicative of the complexity we have in > the standard. The first order of preference should be > to reduce the complexity. I agree with Somesh. When we talked to (some of) the FCP gurus when starting SST, their single most prominent piece of advice was to avoid options and avoid profiles. Seems like motherhood to me. Profiles usually end up being ways of pruning features that a vocal minority thought were critical, and a silent majority didn't really care about and didn't plan to implement. It really makes it hard to figure out what you have to implement, and that's really what happened with FCP. Then again, maybe such surprises are in somebody's interest (heck if I can figure out whom). Personally, I think we're much better of starting out with a rock-solid, interoperable first step, and extending from there, than starting with a specification that covers many anticipated possibilities that we may get around to eventually. The IP protocol suite was developed along those lines (start with something basic, and then tweak and enhance), and it's worked out well. SCSI itself followed that model (ah those grand days before queuing, and single drop links). OSI followed the architect everything before we understand approach and, well at least 2 of those layers fell unused, not to mention the protocols themselves. Nonetheless, if y'all really think the spec has to option laden, it has to be option laden, and NO profiles. If we make this mess, we should lie in it. Steph From owner-ips@ece.cmu.edu Fri Jun 22 00:24:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27790 for ; Fri, 22 Jun 2001 00:24:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5M1fmc07974 for ips-outgoing; Thu, 21 Jun 2001 21:41:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5M1flg07970 for ; Thu, 21 Jun 2001 21:41:47 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id VAA14422 for ips@ece.cmu.edu; Thu, 21 Jun 2001 21:41:46 -0400 (EDT) Date: Thu, 21 Jun 2001 21:41:46 -0400 (EDT) From: Scott Bradner Message-Id: <200106220141.VAA14422@newdev.harvard.edu> To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI Sender: owner-ips@ece.cmu.edu Precedence: bulk note that this AD would not support publishing a IPS protocol that includes profiles - it is my opinion that the existance of profiles indicates a failed standards process in most cases Scott From owner-ips@ece.cmu.edu Fri Jun 22 12:32:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29452 for ; Fri, 22 Jun 2001 12:32:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MEKA002916 for ips-outgoing; Fri, 22 Jun 2001 10:20:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (IDENT:root@va2mc.ummailbox.net [64.210.247.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5MEK5g02901 for ; Fri, 22 Jun 2001 10:20:09 -0400 (EDT) Received: from HQMailWeb.Crossroads.com [63.237.99.250:25] by va2mc.ummailbox.net with SMTP id A0622-1019-6c7108; Fri, 22 Jun 2001 14:19:56 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 22 Jun 2001 09:19:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: profiles - a way to simplify iSCSI Date: Fri, 22 Jun 2001 09:19:47 -0500 Message-ID: Thread-Topic: profiles - a way to simplify iSCSI Thread-Index: AcD6eqYln+S8b8E5Rb2lHZnGjJ02WgAqmmDg From: "Robert Griswold" To: Cc: X-OriginalArrivalTime: 22 Jun 2001 14:19:48.0117 (UTC) FILETIME=[6494B450:01C0FB26] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f5MEK9g02913 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian: Well, drawing on my experience from the consumer storage specs (ATA/ATAPI/MMC), profiles and features lead to huge interoperability problems. The issue for robust (full featured) targets and initiators is they have to chase down every single interpretation of feature sets, some that they don't even care about, so the devices are not caught in transport or command sequences they have no idea about. I am in agreement with David Black and others who have specified that the iSCSI transport needs simplicity rather than complexity; I fear that providing still more optional implementations would lead to more problems. If we believe the hype from the press, then iSCSI will make for cheap targets, which means fast product schedules and low engineering and test coverage from companies that could ship millions of little iSCSI boxes. A tighter iSCSI specification might help keep some of these potential interoperability problems from becoming wildfires. Bob Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] Sent: Thursday, June 21, 2001 12:15 PM To: ips@ece.cmu.edu Subject: profiles - a way to simplify iSCSI Dear colleagues, iSCSI keeps getting richer in negotiable parameters/features. Although flexibility is a great thing every new negotiable parameter/feature get us all worrying about: what it will break when used in combination with other parameters/features how are we going to test that all our combinations work as we think that they are specified are we understanding/specifying the combinations the same way as anybody else I assume that many of you are wondering, as I do, if all this flexibility is really worth it's price. Would the community not be better served by specifying profiles that are a complete-and-invariable combination of features and very small set of numerical parameters? I would start with 2 profiles: the minimal profile (only basic features) the maximum profile (all the features) and then (only if we are strongly convinced it is needed) add a middle point. Please comment, Julo From owner-ips@ece.cmu.edu Fri Jun 22 14:49:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04433 for ; Fri, 22 Jun 2001 14:49:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MHCDQ14931 for ips-outgoing; Fri, 22 Jun 2001 13:12:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from [192.168.90.11] (mail.ams.de [195.30.77.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5MFhpg09158 for ; Fri, 22 Jun 2001 11:43:51 -0400 (EDT) Received: from excadva.advaoptical.de (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 22 Jun 2001 17:43:13 +0200 Received: by excadva.advaoptical.de with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 17:43:32 +0200 Message-ID: <79CB6B56B942D411A9AB001083FCE91E10B509@san-exchange.dino> From: John Vrabel To: ips@ece.cmu.edu Subject: RE: profiles - a way to simplify iSCSI Date: Fri, 22 Jun 2001 17:43:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > It's time to start thinking about what we can take out ... I fully agree with the need to limit options, and avoid the need for profiles. FWIW, our list of things to remove: 1) Markers 2) SNACKs 3) Command retries 4) Async Messages 5) Multiple connections per session Things to change: 1) default number of connections from 8 to 1 ( if multiple connections remain ) Things I'm less sure about: 1) InitialR2T, ImmediateData. Do they really need to be negotiable? FirstBurstSize controls them to a great extent. Can InitialR2T be removed, and retain ImmediateData for short writes ? John Vrabel From owner-ips@ece.cmu.edu Fri Jun 22 14:50:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04507 for ; Fri, 22 Jun 2001 14:50:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MHC2F14919 for ips-outgoing; Fri, 22 Jun 2001 13:12:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5MF9fg06540 for ; Fri, 22 Jun 2001 11:09:41 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA113724 for ; Fri, 22 Jun 2001 17:09:33 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5MF9Y771000 for ; Fri, 22 Jun 2001 17:09:34 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A73.00531907 ; Fri, 22 Jun 2001 17:07:38 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Fri, 22 Jun 2001 18:15:19 +0300 Subject: RE: profiles - a way to simplify iSCSI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, Profiles are meant INSTEAD -OF not in addition to the current set of features. I appreciate your concerns but I think that I must have misstated the profile intention. A profile will be an exact mapping of a set of functions we have today. As such it will be SIMPLER both to implement and test. Julo "Robert Griswold" on 22-06-2001 17:19:47 Please respond to "Robert Griswold" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: profiles - a way to simplify iSCSI Julian: Well, drawing on my experience from the consumer storage specs (ATA/ATAPI/MMC), profiles and features lead to huge interoperability problems. The issue for robust (full featured) targets and initiators is they have to chase down every single interpretation of feature sets, some that they don't even care about, so the devices are not caught in transport or command sequences they have no idea about. I am in agreement with David Black and others who have specified that the iSCSI transport needs simplicity rather than complexity; I fear that providing still more optional implementations would lead to more problems. If we believe the hype from the press, then iSCSI will make for cheap targets, which means fast product schedules and low engineering and test coverage from companies that could ship millions of little iSCSI boxes. A tighter iSCSI specification might help keep some of these potential interoperability problems from becoming wildfires. Bob Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] Sent: Thursday, June 21, 2001 12:15 PM To: ips@ece.cmu.edu Subject: profiles - a way to simplify iSCSI Dear colleagues, iSCSI keeps getting richer in negotiable parameters/features. Although flexibility is a great thing every new negotiable parameter/feature get us all worrying about: what it will break when used in combination with other parameters/features how are we going to test that all our combinations work as we think that they are specified are we understanding/specifying the combinations the same way as anybody else I assume that many of you are wondering, as I do, if all this flexibility is really worth it's price. Would the community not be better served by specifying profiles that are a complete-and-invariable combination of features and very small set of numerical parameters? I would start with 2 profiles: the minimal profile (only basic features) the maximum profile (all the features) and then (only if we are strongly convinced it is needed) add a middle point. Please comment, Julo From owner-ips@ece.cmu.edu Fri Jun 22 15:56:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07575 for ; Fri, 22 Jun 2001 15:56:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MIPIR19284 for ips-outgoing; Fri, 22 Jun 2001 14:25:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5MIPEg19252 for ; Fri, 22 Jun 2001 14:25:14 -0400 (EDT) Received: from sdsl-216-36-75-164.dsl.sjc.megapath.net (HELO somesh) (216.36.75.164) by smtp.mail.vip.sc5.yahoo.com with SMTP; 22 Jun 2001 18:25:12 -0000 X-Apparently-From: Reply-To: From: "Somesh Gupta" To: , Subject: RE: profiles - a way to simplify iSCSI Date: Fri, 22 Jun 2001 11:16:33 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I think a number of our colleagues are speaking about the complexity of the spec as it stands today and the need to reduce the complexity. As I said, if a reasonable profile gets agreed upon (I apologise in advance but I have not seen the ability to say no to feature creep here), then that will become the de-facto standard. And everything else will be an appendage. We might as well do that to start with. It is much better to do that, and as Steph suggested, add features that are required in a newer rev of the spec. It is not as if standards don't evolve. John Vrabel's message indicates a very good starting point for pruning the spec (I disagree on the asynch messages). Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Friday, June 22, 2001 8:15 AM > To: ips@ece.cmu.edu > Subject: RE: profiles - a way to simplify iSCSI > > > > > Robert, > > Profiles are meant INSTEAD -OF not in addition to the current set of > features. > I appreciate your concerns but I think that I must have misstated the > profile intention. > A profile will be an exact mapping of a set of functions we have today. > As such it will be SIMPLER both to implement and test. > > Julo > > "Robert Griswold" on 22-06-2001 17:19:47 > > Please respond to "Robert Griswold" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: profiles - a way to simplify iSCSI > > > > > Julian: > > Well, drawing on my experience from the consumer storage specs > (ATA/ATAPI/MMC), profiles and features lead to huge interoperability > problems. The issue for robust (full featured) targets and initiators > is they have to chase down every single interpretation of feature sets, > some that they don't even care about, so the devices are not caught in > transport or command sequences they have no idea about. I am in > agreement with David Black and others who have specified that the iSCSI > transport needs simplicity rather than complexity; I fear that providing > still more optional implementations would lead to more problems. If we > believe the hype from the press, then iSCSI will make for cheap targets, > which means fast product schedules and low engineering and test coverage > from companies that could ship millions of little iSCSI boxes. A > tighter iSCSI specification might help keep some of these potential > interoperability problems from becoming wildfires. > > Bob > > Robert Griswold > Technologist > Crossroads Systems, Inc. > 512-928-7272 > > -----Original Message----- > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] > Sent: Thursday, June 21, 2001 12:15 PM > To: ips@ece.cmu.edu > Subject: profiles - a way to simplify iSCSI > > > > Dear colleagues, > > iSCSI keeps getting richer in negotiable parameters/features. > Although flexibility is a great thing every new negotiable > parameter/feature get us all worrying about: > > what it will break when used in combination with other > parameters/features > how are we going to test that all our combinations work as we think > that > they are specified > are we understanding/specifying the combinations the same way as > anybody > else > > > I assume that many of you are wondering, as I do, if all this > flexibility > is really worth it's price. > Would the community not be better served by specifying profiles that are > a > complete-and-invariable combination of features and very small set of > numerical parameters? > > I would start with 2 profiles: > > the minimal profile (only basic features) > the maximum profile (all the features) > > and then (only if we are strongly convinced it is needed) add a middle > point. > > Please comment, > Julo > > > > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ips@ece.cmu.edu Fri Jun 22 15:56:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07586 for ; Fri, 22 Jun 2001 15:56:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MI6P718233 for ips-outgoing; Fri, 22 Jun 2001 14:06:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5MI6Mg18223 for ; Fri, 22 Jun 2001 14:06:22 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA22610 for ; Fri, 22 Jun 2001 14:06:16 -0400 (EDT) Message-ID: <3B33881A.D0568785@cisco.com> Date: Fri, 22 Jun 2001 13:02:02 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 CC: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI References: <79CB6B56B942D411A9AB001083FCE91E10B509@san-exchange.dino> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We've been thinking about how to profile iSCSI implementations as well, and Paul Congdon, Matthew Burbridge (both of HP) and I have come up with a spreadsheet that sort of follows the PICS pro-forma that the IEEE folks use. Anyway, it appears that this might be a useful thing to start discussing. We have attempted to list the major mandatory and optional features, but have not had enough review time yet to guarantee that it exactly matches the spec, so comments are welcome. Julian has placed it on his web page at: http://www.haifa.il.ibm.com/satran/ips/iSCSIv6_PICs-5.pdf I apologize that this is not in internet-draft form, or if this list is not exactly the right place to do this. However, I think that it will help show the sheer number of optional features we are faced with, and may help us prioritize what must stay in the protocol, and what we could live without in the interest of simplicity. Hopefully, this will help. -- Mark -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jun 22 15:56:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07597 for ; Fri, 22 Jun 2001 15:56:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MIYlC19788 for ips-outgoing; Fri, 22 Jun 2001 14:34:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5MIYkg19783 for ; Fri, 22 Jun 2001 14:34:46 -0400 (EDT) Received: from HQMailWeb.Crossroads.com [63.237.99.250:25] by va2mc.ummailbox.net with SMTP id J0622-1434-122100; Fri, 22 Jun 2001 18:34:38 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 22 Jun 2001 13:29:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: profiles - a way to simplify iSCSI Date: Fri, 22 Jun 2001 13:29:21 -0500 Message-ID: Thread-Topic: profiles - a way to simplify iSCSI Thread-Index: AcD7Q5rFmYa4ZpzASOauHCuXNXaQLgAA5DDg From: "Robert Griswold" To: Cc: X-OriginalArrivalTime: 22 Jun 2001 18:29:22.0272 (UTC) FILETIME=[41DF6E00:01C0FB49] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f5MIYkg19784 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julo: That is exactly what the MMC and ATA/ATAPI specifications do, the declare the basics; options and required, then group them into functional profiles or feature sets. Setting off minimums, maximums and middle ranges will create classes and sub-classes of implementations. This will force those who don't create end-node targets to have deep understandings of problems associated with feature set misinterpretations, and convert un-implemented commands and responses for different levels of feature implementation. I am all for making it easier, and if this group can make it easier and more reliable with this effort, then I am up to learning all about it. My past experience tells me this could be difficult. I will attempt an unbiased watching of this as it develops. Good Luck. Bob Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] Sent: Friday, June 22, 2001 10:15 AM To: ips@ece.cmu.edu Subject: RE: profiles - a way to simplify iSCSI Robert, Profiles are meant INSTEAD -OF not in addition to the current set of features. I appreciate your concerns but I think that I must have misstated the profile intention. A profile will be an exact mapping of a set of functions we have today. As such it will be SIMPLER both to implement and test. Julo "Robert Griswold" on 22-06-2001 17:19:47 Please respond to "Robert Griswold" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: profiles - a way to simplify iSCSI Julian: Well, drawing on my experience from the consumer storage specs (ATA/ATAPI/MMC), profiles and features lead to huge interoperability problems. The issue for robust (full featured) targets and initiators is they have to chase down every single interpretation of feature sets, some that they don't even care about, so the devices are not caught in transport or command sequences they have no idea about. I am in agreement with David Black and others who have specified that the iSCSI transport needs simplicity rather than complexity; I fear that providing still more optional implementations would lead to more problems. If we believe the hype from the press, then iSCSI will make for cheap targets, which means fast product schedules and low engineering and test coverage from companies that could ship millions of little iSCSI boxes. A tighter iSCSI specification might help keep some of these potential interoperability problems from becoming wildfires. Bob Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] Sent: Thursday, June 21, 2001 12:15 PM To: ips@ece.cmu.edu Subject: profiles - a way to simplify iSCSI Dear colleagues, iSCSI keeps getting richer in negotiable parameters/features. Although flexibility is a great thing every new negotiable parameter/feature get us all worrying about: what it will break when used in combination with other parameters/features how are we going to test that all our combinations work as we think that they are specified are we understanding/specifying the combinations the same way as anybody else I assume that many of you are wondering, as I do, if all this flexibility is really worth it's price. Would the community not be better served by specifying profiles that are a complete-and-invariable combination of features and very small set of numerical parameters? I would start with 2 profiles: the minimal profile (only basic features) the maximum profile (all the features) and then (only if we are strongly convinced it is needed) add a middle point. Please comment, Julo From owner-ips@ece.cmu.edu Fri Jun 22 18:35:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13786 for ; Fri, 22 Jun 2001 18:35:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MKswV29569 for ips-outgoing; Fri, 22 Jun 2001 16:54:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5MKsug29564 for ; Fri, 22 Jun 2001 16:54:57 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id E0116BC6 for ; Fri, 22 Jun 2001 14:54:55 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 8E55F639 for ; Fri, 22 Jun 2001 14:54:55 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id NAA08735 for ; Fri, 22 Jun 2001 13:54:54 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA3EFE for ; Fri, 22 Jun 2001 13:54:52 -0700 Message-ID: <3B33B119.7921F385@agilent.com> Date: Fri, 22 Jun 2001 13:56:57 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI References: <79CB6B56B942D411A9AB001083FCE91E10B509@san-exchange.dino> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The whole purpose for creating iSCSI in the first place (by the group that started it) was to create a storage interconnect that could take advantage of the very high performance promised by 10GBE, at low cost. Mutliple connections per session is there to take advantage of the 10GBE link with the shortcomings of TCP, and markers are there to eliminate the cost of memory subsystems required to buffer out of order TCP frames. Eliminate these, and you've you'll capitulate to Fibre Channel for anything but slow storage connects. -Matt John Vrabel wrote: > > > It's time to start thinking about what we can take out ... > > I fully agree with the need to limit options, and avoid the need for > profiles. > > FWIW, our list of things to remove: > > 1) Markers > > 2) SNACKs > > 3) Command retries > > 4) Async Messages > > 5) Multiple connections per session > > Things to change: > > 1) default number of connections from 8 to 1 ( if multiple connections > remain ) > > Things I'm less sure about: > > 1) InitialR2T, ImmediateData. Do they really need to be negotiable? > FirstBurstSize controls them to a great extent. > Can InitialR2T be removed, and retain ImmediateData for short > writes ? > > John Vrabel From owner-ips@ece.cmu.edu Fri Jun 22 18:38:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13853 for ; Fri, 22 Jun 2001 18:38:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5ML3Tn00192 for ips-outgoing; Fri, 22 Jun 2001 17:03:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5ML3Rg00182 for ; Fri, 22 Jun 2001 17:03:27 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA24460 for ; Fri, 22 Jun 2001 17:03:21 -0400 (EDT) Message-ID: <3B33B19A.3F5DC21C@cisco.com> Date: Fri, 22 Jun 2001 15:59:06 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI References: <79CB6B56B942D411A9AB001083FCE91E10B509@san-exchange.dino> <3B33881A.D0568785@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Just noticed that we did not include descriptions for the columns in the spreadsheet. Here they are: 1st column - Section number of an internet-draft version of this spreadsheet, which we will generate if needed. 2nd column - Category; we divided up the different features into some categories that made sense to us. The first set is common to all iSCSI implementations; the second and third are for those features that apply just to targets or initiators. 3rd column - Feature; short description of each feature. 4th column - Reference; a reference to the section number of the iSCSI document that best describes the feature and its status. 5th column - Status. M = Mandatory O = Optional R = Recommended (we have none of these now) X = Prohibited (we have none of these, either) If numbers appear after the status, e.g. M:4.5, it means that the feature is mandatory if the feature numbered 4.5 is implemented. I just noticed that some of our numbers had changed, so a few of these might still be typos. 6th column - Value. This is used if the feature is more than just a check box; for instance, if an implementation supports "Data Digest - Other", it is used to indicate some reference to what "other" means. Hope this helps, Mark Mark Bakke wrote: > > We've been thinking about how to profile iSCSI implementations > as well, and Paul Congdon, Matthew Burbridge (both of HP) and > I have come up with a spreadsheet that sort of follows the PICS > pro-forma that the IEEE folks use. Anyway, it appears that this > might be a useful thing to start discussing. We have attempted > to list the major mandatory and optional features, but have not > had enough review time yet to guarantee that it exactly matches > the spec, so comments are welcome. > > Julian has placed it on his web page at: > > http://www.haifa.il.ibm.com/satran/ips/iSCSIv6_PICs-5.pdf > > I apologize that this is not in internet-draft form, or if this > list is not exactly the right place to do this. However, I think > that it will help show the sheer number of optional features we > are faced with, and may help us prioritize what must stay in the > protocol, and what we could live without in the interest of > simplicity. > > Hopefully, this will help. > > -- > Mark > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jun 22 19:28:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14964 for ; Fri, 22 Jun 2001 19:28:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MLlIL03234 for ips-outgoing; Fri, 22 Jun 2001 17:47:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5M786g27910 for ; Fri, 22 Jun 2001 03:08:06 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id JAA261742 for ; Fri, 22 Jun 2001 09:07:59 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5M77xg60214 for ; Fri, 22 Jun 2001 09:07:59 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A73.002703D8 ; Fri, 22 Jun 2001 09:06:08 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Fri, 22 Jun 2001 10:13:49 +0300 Subject: RE: profiles - a way to simplify iSCSI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Somesh, I am saying (loud and clear) PROFILES WILL ELIMINATE negotiation (except some numeric values). Regards, Julo "Somesh Gupta" on 21-06-2001 21:59:09 Please respond to someshg@yahoo.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: profiles - a way to simplify iSCSI I think this is indicative of the complexity we have in the standard. The first order of preference should be to reduce the complexity. Secondly, given the confusing decision process in the IETF, it is not certain whether we would meet the following two goals that I would have 1. Speedy process. 2. A large community of vendors and customers agreeing on an ideal profile that would be implemented widely. (of course, that means that everything else in the spec would be relegated to the position where 5 yrs from now only few will be able to explain why it is in the spec) Otherwise profiles are just going to add another dimension to negotiate without providing much benefit. Unless you say that profiles completely eliminate parameter negotiation (then it does add a lot of value). Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Thursday, June 21, 2001 10:15 AM > To: ips@ece.cmu.edu > Subject: profiles - a way to simplify iSCSI > > > > > Dear colleagues, > > iSCSI keeps getting richer in negotiable parameters/features. > Although flexibility is a great thing every new negotiable > parameter/feature get us all worrying about: > > what it will break when used in combination with other > parameters/features > how are we going to test that all our combinations work as we > think that > they are specified > are we understanding/specifying the combinations the same way > as anybody > else > > > I assume that many of you are wondering, as I do, if all this flexibility > is really worth it's price. > Would the community not be better served by specifying profiles that are a > complete-and-invariable combination of features and very small set of > numerical parameters? > > I would start with 2 profiles: > > the minimal profile (only basic features) > the maximum profile (all the features) > > and then (only if we are strongly convinced it is needed) add a middle > point. > > Please comment, > Julo > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ips@ece.cmu.edu Fri Jun 22 19:32:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15148 for ; Fri, 22 Jun 2001 19:32:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MLlFX03228 for ips-outgoing; Fri, 22 Jun 2001 17:47:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5M7QWg28943 for ; Fri, 22 Jun 2001 03:26:32 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id JAA349182 for ; Fri, 22 Jun 2001 09:26:25 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5M7QPg36604 for ; Fri, 22 Jun 2001 09:26:25 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A73.0028B364 ; Fri, 22 Jun 2001 09:24:33 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Fri, 22 Jun 2001 10:32:09 +0300 Subject: RE: profiles - a way to simplify iSCSI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I would like to clarify a semantic nit before a go to your more substantive questions. I do not mean that we have to introduce profiles (as some other RFCs have) as accompanying docs but rather make 2 or 3 profiles part of iSCSI and have them REPLACE the plethora or features we have now and will contain a fixed set of capabilities (e.g. a device that declares itself profile 0 has only the features mandatory to implement while a device that declares itself profile-x has all the mandatory and optional features). As for why do we have so many things that can be negotiated - I think we have less than many other standards but we have to face the fact that different segments of our community target different parts of the SCSI solutions domain and each of the have legitimate concerns about functions and price. Julo Black_David@emc.com on 22-06-2001 02:23:28 Please respond to Black_David@emc.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: profiles - a way to simplify iSCSI > iSCSI keeps getting richer in negotiable parameters/features. > Although flexibility is a great thing every new negotiable > parameter/feature get us all worrying about: > > what it will break when used in combination with other > parameters/features > how are we going to test that all our combinations work as we think that > they are specified > are we understanding/specifying the combinations the same way as anybody > else All worthy questions, but I think one important one is left out - Why does iSCSI have so many negotiable parameters/features? This leads into ... > I assume that many of you are wondering, as I do, if all this flexibility > is really worth it's price. If it leads to implementations that fail to interoperate, the answer is "no". > Would the community not be better served by specifying profiles that are a > complete-and-invariable combination of features and very small set of > numerical parameters? I think it's incumbent on the WG to reduce the amount of flexibility by removing things and restricting implementation flexibility (e.g., specifying that for a certain set of features implementations MUST support all of the features in the set if they support any one of them). This belongs in the main body of the specification, not a separate profile. See RFC 2119 for the appropriate terms to use in specifying requirements for implementations. IMHO, if a specification requires profiles in order to obtain interoperable implementations, then the specification itself is insufficiently precise and needs to be tightened in order to merit approval as a proposed standard RFC. It's time to start thinking about what we can take out ... Writing as an IPS WG co-chair, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Jun 22 19:33:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15188 for ; Fri, 22 Jun 2001 19:33:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MLlSM03259 for ips-outgoing; Fri, 22 Jun 2001 17:47:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5M6l3g26712 for ; Fri, 22 Jun 2001 02:47:03 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA291698 for ; Fri, 22 Jun 2001 08:46:49 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5M6km723942 for ; Fri, 22 Jun 2001 08:46:48 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A73.0025139D ; Fri, 22 Jun 2001 08:44:58 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Fri, 22 Jun 2001 09:52:39 +0300 Subject: Re: profiles - a way to simplify iSCSI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, Yes. Profiles will be all or nothing and the what is mandated in every profile will appear in the draft and what is not mandated at a profile will never be used (can as well not be there). A simple two profile scheme can be built using as a profile 0 whatever is today mandatory (or defaulted to yes or equivalent) and as profile one everything else. Regards, Julo Sandeep Joshi on 21-06-2001 21:19:21 Please respond to Sandeep Joshi To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI Hmm..this is somewhat tempting.  The parameters seem to fall into 2-3 clusters (1) initialR2T, maxR2T, immediate data, firstburst, pdulength, etc (2) the marker related keys (3) names, aliases, bootsession, maxconnections, loginlogout min-max. It would be nice if a "profile" could simplify these dependencies. Under this proposed setup, I presume the target & initiator would first send a profile-name which would initialize the appropriate parameters in the set. If a vendor is unsure of a particular profile, support for it would not be advertised. Once a profile is decided, only numeric keys would be negotiated. Could you elaborate further on your proposal ? -Sandeep julian_satran@il.ibm.com wrote: > > Dear colleagues, > > iSCSI keeps getting richer in negotiable parameters/features. > Although flexibility is a great thing every new negotiable > parameter/feature get us all worrying about: > > what it will break when used in combination with other > parameters/features > how are we going to test that all our combinations work as we think that > they are specified > are we understanding/specifying the combinations the same way as anybody > else > > I assume that many of you are wondering, as I do, if all this flexibility > is really worth it's price. > Would the community not be better served by specifying profiles that are a > complete-and-invariable combination of features and very small set of > numerical parameters? > > I would start with 2 profiles: > > the minimal profile (only basic features) > the maximum profile (all the features) > > and then (only if we are strongly convinced it is needed) add a middle > point. > > Please comment, > Julo From owner-ips@ece.cmu.edu Fri Jun 22 20:58:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17198 for ; Fri, 22 Jun 2001 20:58:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MNDSD08563 for ips-outgoing; Fri, 22 Jun 2001 19:13:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5MNDQg08558 for ; Fri, 22 Jun 2001 19:13:26 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id TAA18857 for ips@ece.cmu.edu; Fri, 22 Jun 2001 19:13:25 -0400 (EDT) Date: Fri, 22 Jun 2001 19:13:25 -0400 (EDT) From: Scott Bradner Message-Id: <200106222313.TAA18857@newdev.harvard.edu> To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI Sender: owner-ips@ece.cmu.edu Precedence: bulk there seems to be a misunderstanding somewhere - I was trying to say nicely that a IPS protocol that has to have profiles would not pass the IESG but I guess I was too nice - I expect that teh IESG would return any such proposal to the WG for rework if such a proposal makes it to the IESG i.e the discussion in the followintg posting is not a productive path to be following Scott (one of the TSV area directors) ----- From owner-ips@ece.cmu.edu Fri Jun 22 17:05:13 2001 X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Date: Fri, 22 Jun 2001 15:59:06 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI References: <79CB6B56B942D411A9AB001083FCE91E10B509@san-exchange.dino> <3B33881A.D0568785@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Just noticed that we did not include descriptions for the columns in the spreadsheet. Here they are: 1st column - Section number of an internet-draft version of this spreadsheet, which we will generate if needed. 2nd column - Category; we divided up the different features into some categories that made sense to us. The first set is common to all iSCSI implementations; the second and third are for those features that apply just to targets or initiators. 3rd column - Feature; short description of each feature. 4th column - Reference; a reference to the section number of the iSCSI document that best describes the feature and its status. 5th column - Status. M = Mandatory O = Optional R = Recommended (we have none of these now) X = Prohibited (we have none of these, either) If numbers appear after the status, e.g. M:4.5, it means that the feature is mandatory if the feature numbered 4.5 is implemented. I just noticed that some of our numbers had changed, so a few of these might still be typos. 6th column - Value. This is used if the feature is more than just a check box; for instance, if an implementation supports "Data Digest - Other", it is used to indicate some reference to what "other" means. Hope this helps, Mark Mark Bakke wrote: > > We've been thinking about how to profile iSCSI implementations > as well, and Paul Congdon, Matthew Burbridge (both of HP) and > I have come up with a spreadsheet that sort of follows the PICS > pro-forma that the IEEE folks use. Anyway, it appears that this > might be a useful thing to start discussing. We have attempted > to list the major mandatory and optional features, but have not > had enough review time yet to guarantee that it exactly matches > the spec, so comments are welcome. > > Julian has placed it on his web page at: > > http://www.haifa.il.ibm.com/satran/ips/iSCSIv6_PICs-5.pdf > > I apologize that this is not in internet-draft form, or if this > list is not exactly the right place to do this. However, I think > that it will help show the sheer number of optional features we > are faced with, and may help us prioritize what must stay in the > protocol, and what we could live without in the interest of > simplicity. > > Hopefully, this will help. > > -- > Mark > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jun 22 21:05:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17365 for ; Fri, 22 Jun 2001 21:05:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MNXhM09717 for ips-outgoing; Fri, 22 Jun 2001 19:33:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.6.9.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5MNXgg09713 for ; Fri, 22 Jun 2001 19:33:42 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 2A9B3A04 for ; Fri, 22 Jun 2001 17:33:41 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id BF4D8526 for ; Fri, 22 Jun 2001 17:33:40 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id QAA24093 for ; Fri, 22 Jun 2001 16:33:39 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA51E7 for ; Fri, 22 Jun 2001 16:33:36 -0700 Message-ID: <3B33D64C.F0CC359A@agilent.com> Date: Fri, 22 Jun 2001 16:35:40 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Why have two profiles? Just like in fibre channel, have one profile that describes the parameters to be used to be interoperable with other devices (would be your profile 0). The other profile is simply the iSCSI spec, where everything is open and negotiable. -Matt julian_satran@il.ibm.com wrote: > > Sandeep, > > Yes. Profiles will be all or nothing and the what is mandated in every > profile will appear in the draft and what is not mandated at a profile will > never be used (can as well not be there). > > A simple two profile scheme can be built using as a profile 0 whatever is > today mandatory > (or defaulted to yes or equivalent) and as profile one everything else. > > Regards, > Julo From owner-ips@ece.cmu.edu Fri Jun 22 21:16:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17575 for ; Fri, 22 Jun 2001 21:16:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5MNlfb10475 for ips-outgoing; Fri, 22 Jun 2001 19:47:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5MNleg10471 for ; Fri, 22 Jun 2001 19:47:40 -0400 (EDT) Received: from sdsl-216-36-75-164.dsl.sjc.megapath.net (HELO somesh) (216.36.75.164) by smtp.mail.vip.sc5.yahoo.com with SMTP; 22 Jun 2001 23:47:39 -0000 X-Apparently-From: Reply-To: From: "Somesh Gupta" To: "Matt Wakeley" , Subject: RE: profiles - a way to simplify iSCSI Date: Fri, 22 Jun 2001 16:38:59 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3B33B119.7921F385@agilent.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Matt Wakeley > Sent: Friday, June 22, 2001 1:57 PM > To: ips@ece.cmu.edu > Subject: Re: profiles - a way to simplify iSCSI > > > The whole purpose for creating iSCSI in the first place (by the group that > started it) was to create a storage interconnect that could take > advantage of > the very high performance promised by 10GBE, at low cost. And share a common infrastructure (including common adapters) with all other data center apps such as NAS, http etc. > Mutliple > connections per session is there to take advantage of the 10GBE > link with the > shortcomings of TCP, How? By skipping around the congestion control algorithms? What about the other flows in the network? > and markers are there to eliminate the cost of memory > subsystems required to buffer out of order TCP frames. Framing has other benefit but not having a fast memory system cannot be avoided (especially if the inrastructure is to be common.) Also markers and CRCs do not mix well together. > Eliminate > these, and > you've you'll capitulate to Fibre Channel for anything but slow storage > connects. I don't think so. The pull of a common infrastructure will be too strong. And in case you have not looked lately, memory is getting fast enough and cheap enough. The GigaHz PCs are driving this. Somesh > > -Matt > > John Vrabel wrote: > > > > > It's time to start thinking about what we can take out ... > > > > I fully agree with the need to limit options, and avoid the need for > > profiles. > > > > FWIW, our list of things to remove: > > > > 1) Markers > > > > 2) SNACKs > > > > 3) Command retries > > > > 4) Async Messages > > > > 5) Multiple connections per session > > > > Things to change: > > > > 1) default number of connections from 8 to 1 ( if multiple > connections > > remain ) > > > > Things I'm less sure about: > > > > 1) InitialR2T, ImmediateData. Do they really need to be > negotiable? > > FirstBurstSize controls them to a great extent. > > Can InitialR2T be removed, and retain ImmediateData for short > > writes ? > > > > John Vrabel _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ips@ece.cmu.edu Fri Jun 22 21:55:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18894 for ; Fri, 22 Jun 2001 21:55:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5N09S411671 for ips-outgoing; Fri, 22 Jun 2001 20:09:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5N09Rg11666 for ; Fri, 22 Jun 2001 20:09:27 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 20:11:11 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E07093A@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI simplification Date: Fri, 22 Jun 2001 20:06:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk The word "profiles" is leading to unproductive analogies to profiles that have been used in other standards contexts. Many of the cited examples of profiles in other standards contexts are efforts to clean up interoperability messes after the fact, leading one of our ADs to inform us that making the mess in the first place will not be permitted: > there seems to be a misunderstanding somewhere - I was trying to say > nicely that a IPS protocol that has to have profiles would not pass > the IESG but I guess I was too nice - Not only will it not pass the IESG - it's rather unlikely to get to WG Last Call, as your WG co-chairs have a duty not to Last Call a document in that state. In particular, the Fibre Channel profiles are (unfortunately) examples of what not to do. We need to use words other than "profiles" because people don't agree on what that means, and some of the ideas it covers are actually useful. When Julian says: > have them REPLACE the plethora or features we have now and will > contain a fixed set of capabilities this is headed in a useful direction. Rather than using the term "profiles", I would talk about subsets of the protocol and conformance requirements. Truth be told, I did encourage Mark to post a pointer to the spreadsheet, not so much to encourage work on that spreadsheet, but rather, as Mark says: > [...] it will help show the sheer number of optional features we > are faced with, and may help us prioritize what must stay in the > protocol, and what we could live without in the interest of > simplicity. I count over 100 optional items in that listing, a number that has at least one too many zeros. Matt's comment on Fibre Channel use of profiles is an opportunity to make an important point: > Why have two profiles? Just like in fibre channel, have one profile that > describes the parameters to be used to be interoperable with other devices > (would be your profile 0). The other profile is simply the iSCSI spec, where > everything is open and negotiable. The IETF approach to this is to bit-bucket everything not involved in interoperability. The result is that there isn't a need for a "profile 0" because everything outside it is either excised from the spec or has words like "MUST" or "MUST NOT" (cf. RFC 2119) attached to it to indicate what is required for interoperability. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Jun 22 21:58:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18930 for ; Fri, 22 Jun 2001 21:58:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5N0DRm11959 for ips-outgoing; Fri, 22 Jun 2001 20:13:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5N0DPg11953 for ; Fri, 22 Jun 2001 20:13:25 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel1.hp.com (Postfix) with ESMTP id C710813FD; Fri, 22 Jun 2001 17:13:43 -0700 (PDT) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 3B9A11F537; Fri, 22 Jun 2001 17:12:46 -0700 (PDT) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 17:13:23 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09142@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Black_David@emc.com'" , mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Fri, 22 Jun 2001 17:13:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk ..snipping.. > > There's one issue that's not completely clear to me from > the discussion, and that is how to limit the scope of > information that is returned by SendTargets to match what > I believe to be the sense of the discussion that SendTargets's > purpose is to describe the device/implementation/instance > to which it is issued. I can see a couple of choices: > (A) SendTargets only returns information about targets that > are accessible through the to > which the SendTargets was issued. > (B) SendTargets only returns information about targets that > are accessible through an that > can also access the *same* canonical iSCSI target > instance to which the SendTargets was issued. I don't understand what you're thinking of here - SendTargets is intended partly as a discovery mechanism. Why would we limit it to only "only return information about targets that are accessible through an "? What's your concern about "same canonical target"?? > (A) is the simpler one to explain and understand, and may > do a better job of structuring the discovery process (new > iSCSI "instances" can't be discovered as a result of issuing > SendTargets) at the price of potentially having to discover > more iSCSI communication endpoints to which SendTargets > has to be issued at the earlier stage of discovery. This defeats part of the intent of SendTargets? > (B) allows configuration to be centralized in some cases where > (A) does not, but the notion of "*same* canonical iSCSI > target instance" strikes me as hard to define and enforce > in a protocol spec, and opens SendTargets up to > virtualization of the canonical target (e.g., by > replication of state information) in a fashion that could > turn SendTargets into a network-wide discovery mechanism, > which seems contrary to the sense of the discussion. > (A) seems to be the choice that better fits what I > believe the sense of the discussion is. The behavior outlined by the Naming and Discovery team for SendTargets is dependant on what target name an initiator is logged into. SendTarget response: **logged into 'iSCSI' target -> repeating (list of targetname and all associated paths to that name w/aggregation tags) filtered by initiator access rights. **logged into - should be 'report portal groups' flavor of SendTargets where the information is limited to the information about "the target being addressed" rather than a list of all accessible targets for this initiator. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com From owner-ips@ece.cmu.edu Fri Jun 22 23:10:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20651 for ; Fri, 22 Jun 2001 23:10:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5N125K14614 for ips-outgoing; Fri, 22 Jun 2001 21:02:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5N124g14610 for ; Fri, 22 Jun 2001 21:02:04 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 21:03:49 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E07093B@corpmx14.us.dg.com> From: Black_David@emc.com To: marjorie_krueger@hp.com, Black_David@emc.com, mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Fri, 22 Jun 2001 20:59:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Marj, > I don't understand what you're thinking of here - SendTargets is intended > partly as a discovery mechanism. Why would we limit it to only "only return > information about targets that are accessible through an port>"? > > What's your concern about "same canonical target"?? Suppose we have three independent iSCSI systems, X, Y and Z. My understanding of the sense of the discussion is that the desired approach is that an Initiator discovers via some other means that it should talk to X, Y, and Z, and then SendTargets on each system only returns information about targets on that system. Restricting SendTargets to only describe targets accessible through the on which it was issued prevents X from returning information about Y and Z. It also prevents X from returning information about targets on X that are only accessible through other IP addresses and/or TCP ports. This forces more pairs to be discovered prior to issuing Send Targets. That may be a good thing - for example it makes it possible for a management tool to figure out where all of some Initiator's storage is without ever issuing any SendTarget commands. It would be a "bad thing" if the only way to find Y was to issue a SendTargets to X (e.g., simple mistake in configuring X can hide Y from the management tool, even if all the Initiators still work). This argument is somewhat less compelling when we're dealing with two ports on X instead of X and Y. "same canonical target" was an attempt to deal with the "It also prevents ..." sentence above. The concern I have is about someone placing information about X, Y, and Z on all of X, Y, and Z, and then claiming that the "iscsi" canonical target on X, Y, and Z is the same target because the same information is returned in each case. This seems to make the "same " approach preferable. Does that make things clearer? Do you see a need for a SendTargets issued to system X to return information about system Y? Thanks, --David > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) [SMTP:marjorie_krueger@hp.com] > Sent: Friday, June 22, 2001 8:13 PM > To: 'Black_David@emc.com'; mbakke@cisco.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Wrapping up SendTargets > > ..snipping.. > > > > There's one issue that's not completely clear to me from > > the discussion, and that is how to limit the scope of > > information that is returned by SendTargets to match what > > I believe to be the sense of the discussion that SendTargets's > > purpose is to describe the device/implementation/instance > > to which it is issued. I can see a couple of choices: > > (A) SendTargets only returns information about targets that > > are accessible through the to > > which the SendTargets was issued. > > (B) SendTargets only returns information about targets that > > are accessible through an that > > can also access the *same* canonical iSCSI target > > instance to which the SendTargets was issued. > > I don't understand what you're thinking of here - SendTargets is intended > partly as a discovery mechanism. Why would we limit it to only "only > return > information about targets that are accessible through an port>"? > > What's your concern about "same canonical target"?? > > > (A) is the simpler one to explain and understand, and may > > do a better job of structuring the discovery process (new > > iSCSI "instances" can't be discovered as a result of issuing > > SendTargets) at the price of potentially having to discover > > more iSCSI communication endpoints to which SendTargets > > has to be issued at the earlier stage of discovery. > > This defeats part of the intent of SendTargets? > > > (B) allows configuration to be centralized in some cases where > > (A) does not, but the notion of "*same* canonical iSCSI > > target instance" strikes me as hard to define and enforce > > in a protocol spec, and opens SendTargets up to > > virtualization of the canonical target (e.g., by > > replication of state information) in a fashion that could > > turn SendTargets into a network-wide discovery mechanism, > > which seems contrary to the sense of the discussion. > > (A) seems to be the choice that better fits what I > > believe the sense of the discussion is. > > The behavior outlined by the Naming and Discovery team for SendTargets is > dependant on what target name an initiator is logged into. > > SendTarget response: > **logged into 'iSCSI' target -> repeating (list of targetname and > all associated paths to that name w/aggregation tags) > filtered by initiator access rights. > > **logged into - should be 'report portal groups' > flavor of SendTargets where the information is limited to the information > about "the target being addressed" rather than a list of all accessible > targets for this initiator. > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > tel: +1 916 785 2656 > fax: +1 916 785 0391 > email: marjorie_krueger@hp.com From owner-ips@ece.cmu.edu Fri Jun 22 23:10:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20669 for ; Fri, 22 Jun 2001 23:10:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5N1Sie15994 for ips-outgoing; Fri, 22 Jun 2001 21:28:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5N1Shg15990 for ; Fri, 22 Jun 2001 21:28:43 -0400 (EDT) Received: from cs.uchicago.edu ([24.91.87.148]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f5N1Sfx01467 for ; Fri, 22 Jun 2001 21:28:41 -0400 (EDT) Message-Id: <200106230128.f5N1Sfx01467@chmls05.mediaone.net> To: ips@ece.cmu.edu Subject: Re: iSCSI:Text field in Asynchronous Message In-Reply-To: Message from Robert Snively of "Fri, 22 Jun 2001 14:25:27 PDT." References: Date: Fri, 22 Jun 2001 21:28:33 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk Bob, > In general, none of the initiators have a process in place to do > anything with an AEN. Ah, but in specific, CAM-based initiators (Tru64) DO have support for this. I don't know if *BSD (or Netware?) chose to implement SET ASYNC CALLBACK or not. AEN handling such a strong differentiator, I expect Compaq Alphas overtake Sun and HP in the 64-bit server market within the year :^) Steph From owner-ips@ece.cmu.edu Fri Jun 22 23:52:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21572 for ; Fri, 22 Jun 2001 23:52:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5N2Tbo19459 for ips-outgoing; Fri, 22 Jun 2001 22:29:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.6.9.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5N2TZg19455 for ; Fri, 22 Jun 2001 22:29:35 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id C16AF1255 for ; Fri, 22 Jun 2001 20:29:34 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 7B8F8928 for ; Fri, 22 Jun 2001 20:29:34 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id TAA04858 for ; Fri, 22 Jun 2001 19:29:33 -0700 (PDT) Received: from agilent.com (cos1nai128087.cos.agilent.com [141.184.128.87]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA6522 for ; Fri, 22 Jun 2001 19:29:30 -0700 Message-ID: <3B33FF06.575FA548@agilent.com> Date: Fri, 22 Jun 2001 19:29:26 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI simplification References: <277DD60FB639D511AC0400B0D068B71E07093A@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I doubt there will ever be agreement on what to "eliminate".... some people want multiple connections because they think it will improve performance, others want the simplicity of one... some people want CRCs mandated for data integrity... others don't because it slows down their software implementation... some people want markers because it accelerates hw performance and reduces cost... the software implementations will complain about that too, then there's the "warp" camp that will complain because markers eliminate some of their ammunition for getting that. Some want precise error recovery, others want the big hammer approach. And I won't even get into the discovery stuff.... The "interoperability plugfest" will test to two versions of the spec (0 vs 0.6) - that's interoperability for you! -Matt From owner-ips@ece.cmu.edu Fri Jun 22 23:55:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21587 for ; Fri, 22 Jun 2001 23:55:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5N2EZE18570 for ips-outgoing; Fri, 22 Jun 2001 22:14:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5N2EXg18566 for ; Fri, 22 Jun 2001 22:14:33 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id BCE49A42 for ; Fri, 22 Jun 2001 20:14:32 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 5134323F for ; Fri, 22 Jun 2001 20:14:32 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id TAA04273 for ; Fri, 22 Jun 2001 19:14:31 -0700 (PDT) Received: from agilent.com (cos1nai128087.cos.agilent.com [141.184.128.87]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA637D for ; Fri, 22 Jun 2001 19:14:24 -0700 Message-ID: <3B33FB7C.99D99858@agilent.com> Date: Fri, 22 Jun 2001 19:14:20 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Somesh Gupta wrote: > > Mutliple > > connections per session is there to take advantage of the 10GBE > > link with the shortcomings of TCP, > > How? By skipping around the congestion control algorithms? What > about the other flows in the network? Nobody said anything about skipping around congestion control. TCP was not designed for the fast links that are available today, so you'll probably need more than 1 connection to attain link rate. Whether you have 1 or a thousand connections, congestion control will still work (or else it's fundamentally broken anyway). > > and markers are there to eliminate the cost of memory > > subsystems required to buffer out of order TCP frames. > > Framing has other benefit but not having a fast memory > system cannot be avoided (especially if the inrastructure > is to be common.) Also markers and CRCs do not mix well > together. How do they not mix well? > > Eliminate > > these, and > > you've you'll capitulate to Fibre Channel for anything but slow storage > > connects. > > I don't think so. The pull of a common infrastructure will > be too strong. And in case you have not looked lately, > memory is getting fast enough and cheap enough. The GigaHz > PCs are driving this. Until memory becomes "free", iSCSI implementations will always cost more than FC implementations that do not require memory -Matt From owner-ips@ece.cmu.edu Fri Jun 22 23:59:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21666 for ; Fri, 22 Jun 2001 23:59:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5N27pS18257 for ips-outgoing; Fri, 22 Jun 2001 22:07:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5N27og18253 for ; Fri, 22 Jun 2001 22:07:50 -0400 (EDT) Received: from sdsl-216-36-75-164.dsl.sjc.megapath.net (HELO somesh) (216.36.75.164) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jun 2001 02:07:49 -0000 X-Apparently-From: Reply-To: From: "Somesh Gupta" To: , Subject: RE: profiles - a way to simplify iSCSI Date: Fri, 22 Jun 2001 18:59:09 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit and without shouting at you :-) but to repeat myself, let us just come up with one reasonable "profile" i.e. RFC and then we can defer all other features till the next rev when we know what the shortcomings, if any, may be. Regards, Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Friday, June 22, 2001 12:14 AM > To: ips@ece.cmu.edu > Subject: RE: profiles - a way to simplify iSCSI > > > > > Somesh, > > I am saying (loud and clear) PROFILES WILL ELIMINATE negotiation (except > some numeric values). > > Regards, > Julo > > "Somesh Gupta" on 21-06-2001 21:59:09 > > Please respond to someshg@yahoo.com > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: RE: profiles - a way to simplify iSCSI > > > > > I think this is indicative of the complexity we have in > the standard. The first order of preference should be > to reduce the complexity. > > Secondly, given the confusing decision process in the > IETF, it is not certain whether we would meet the following > two goals that I would have > > 1. Speedy process. > 2. A large community of vendors and customers agreeing on > an ideal profile that would be implemented widely. > (of course, that means that everything else in the spec > would be relegated to the position where 5 yrs from now > only few will be able to explain why it is in the spec) > > Otherwise profiles are just going to add another dimension > to negotiate without providing much benefit. Unless you > say that profiles completely eliminate parameter negotiation > (then it does add a lot of value). > > Somesh > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > julian_satran@il.ibm.com > > Sent: Thursday, June 21, 2001 10:15 AM > > To: ips@ece.cmu.edu > > Subject: profiles - a way to simplify iSCSI > > > > > > > > > > Dear colleagues, > > > > iSCSI keeps getting richer in negotiable parameters/features. > > Although flexibility is a great thing every new negotiable > > parameter/feature get us all worrying about: > > > > what it will break when used in combination with other > > parameters/features > > how are we going to test that all our combinations work as we > > think that > > they are specified > > are we understanding/specifying the combinations the same way > > as anybody > > else > > > > > > I assume that many of you are wondering, as I do, if all this > flexibility > > is really worth it's price. > > Would the community not be better served by specifying profiles that are > a > > complete-and-invariable combination of features and very small set of > > numerical parameters? > > > > I would start with 2 profiles: > > > > the minimal profile (only basic features) > > the maximum profile (all the features) > > > > and then (only if we are strongly convinced it is needed) add a middle > > point. > > > > Please comment, > > Julo > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ips@ece.cmu.edu Sat Jun 23 13:48:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14253 for ; Sat, 23 Jun 2001 13:48:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5NFobh10132 for ips-outgoing; Sat, 23 Jun 2001 11:50:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5NFoag10128 for ; Sat, 23 Jun 2001 11:50:36 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA106264 for ; Sat, 23 Jun 2001 10:45:08 -0500 Received: from f4n49e (d03nm065h.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5NFnI4107712 for ; Sat, 23 Jun 2001 09:49:19 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: profiles - a way to simplify iSCSI To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 22 Jun 2001 11:12:41 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/23/2001 09:49:18 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I have been traveling so I did not put my 2 cents in before now. First it is not yet understood what is actually needed and what is not important until things actually get built. At that time the industry will begin to consolidate around the really valuable "Optional to implement". Like was mentioned on this thread, it is the really vocal minority that will yell until an option is included, and the silent majority will go about building what makes since for their customers. Further, the silent majority will remain just that, silent and are not much help when we try to cut back on options. An example of this is all the people that complained about the SW implementations that had to add extra code and path length to support the Markers. Now the important thing is that, all the real SW implementations that are currently being done are being given away for Free by the various Storage and Routers vendors, or as part of a free option from an OS. I know of no one that plans on selling an iSCSI SW iSCSI implementation. Therefore, in the real world, the folks that were complaining, were not going to implement a SW iSCSI version, anyway. They were just debating for effect. And this has been causing some disarray in the HW iSCSI HBAs (Host Buss Adapters) arena. There is probably no way to stop this, and if we attempt to do that, by defining profiles, in the IETF, it will just cause the debates to start all over again. Many of us, I am sure, were glad to have moved on to other topics when a contentious item was made an option, since we knew we were not going to implement it, and doubted if in the real world anyone would. Some of us felt that either the option would not be implemented by two or more vendors, or if it was, the market place would make it go away. The IETF process will address the issue of less then two implementations, and one of the purposes of the SNIA IP Storage Forum and Technical Workgroup is to help define the marketing needs and the profiles that meet these needs. Now let me explain about the marketing needs and their related profiles. As an example there maybe an important market that addresses, iSCSI needs within a Business Secure Campus. There maybe lots of vendors that have products that fit that market, but several vendors may have decided to have a low price point, and not include optional items that would be especially valuable in the Wide Area Market, but not needed in a Business Secure Campus (e.g. extra RAM). This set of vendors might feel that they could meet their revenue goals by focusing only on Business Secure Campuses. Therefore, they might want to define a set of profiles that would permit them to meet their targeted market. I do think we need to clearly define the "Must implement" and that these must be the Minimum Profile. However, it is not clear to me that we need to have profiles defined by the IETF. If profiles are needed anywhere they should be produced as part of the SNIA IP Storage (iSCSI) Technical WorkGroup's response to what the SNIA IP Storage Forum Defines to be a targeted marketing need. (Those, profiles can then be used in conformance test at UNH.) I do not think that profiles should be part of the IETF work. I agree that we should not have more options than will be actually built, however, the IETF process probably limits this to a great extent. Also, I would hate to see us get into the rancorous debates that will follow when we try to limit options, I do not think we added them wily nilly and that each one, at the time, seemed to be of value to some set of vocal people. So I suggest that we be very careful when we try to trim the Options, and then only those that we know do not make since to any potential profile. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sat Jun 23 14:36:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15067 for ; Sat, 23 Jun 2001 14:36:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5NGoJ413268 for ips-outgoing; Sat, 23 Jun 2001 12:50:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5N47og24742 for ; Sat, 23 Jun 2001 00:07:50 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id GAA260776 for ; Sat, 23 Jun 2001 06:07:44 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5N47i736406 for ; Sat, 23 Jun 2001 06:07:44 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A74.001680AB ; Sat, 23 Jun 2001 06:05:47 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sat, 23 Jun 2001 07:09:02 +0300 Subject: RE: profiles - a way to simplify iSCSI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Somesh, You are still missing my point. Profiles are not proposed "in addition" to what we have but instead of. They are not meant to remove features that where introduced for a legitimate reason or another but rather to limit the variability in implementations and testing. Julo "Somesh Gupta" on 22-06-2001 21:16:33 Please respond to someshg@yahoo.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: profiles - a way to simplify iSCSI Julian, I think a number of our colleagues are speaking about the complexity of the spec as it stands today and the need to reduce the complexity. As I said, if a reasonable profile gets agreed upon (I apologise in advance but I have not seen the ability to say no to feature creep here), then that will become the de-facto standard. And everything else will be an appendage. We might as well do that to start with. It is much better to do that, and as Steph suggested, add features that are required in a newer rev of the spec. It is not as if standards don't evolve. John Vrabel's message indicates a very good starting point for pruning the spec (I disagree on the asynch messages). Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Friday, June 22, 2001 8:15 AM > To: ips@ece.cmu.edu > Subject: RE: profiles - a way to simplify iSCSI > > > > > Robert, > > Profiles are meant INSTEAD -OF not in addition to the current set of > features. > I appreciate your concerns but I think that I must have misstated the > profile intention. > A profile will be an exact mapping of a set of functions we have today. > As such it will be SIMPLER both to implement and test. > > Julo > > "Robert Griswold" on 22-06-2001 17:19:47 > > Please respond to "Robert Griswold" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: profiles - a way to simplify iSCSI > > > > > Julian: > > Well, drawing on my experience from the consumer storage specs > (ATA/ATAPI/MMC), profiles and features lead to huge interoperability > problems. The issue for robust (full featured) targets and initiators > is they have to chase down every single interpretation of feature sets, > some that they don't even care about, so the devices are not caught in > transport or command sequences they have no idea about. I am in > agreement with David Black and others who have specified that the iSCSI > transport needs simplicity rather than complexity; I fear that providing > still more optional implementations would lead to more problems. If we > believe the hype from the press, then iSCSI will make for cheap targets, > which means fast product schedules and low engineering and test coverage > from companies that could ship millions of little iSCSI boxes. A > tighter iSCSI specification might help keep some of these potential > interoperability problems from becoming wildfires. > > Bob > > Robert Griswold > Technologist > Crossroads Systems, Inc. > 512-928-7272 > > -----Original Message----- > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] > Sent: Thursday, June 21, 2001 12:15 PM > To: ips@ece.cmu.edu > Subject: profiles - a way to simplify iSCSI > > > > Dear colleagues, > > iSCSI keeps getting richer in negotiable parameters/features. > Although flexibility is a great thing every new negotiable > parameter/feature get us all worrying about: > > what it will break when used in combination with other > parameters/features > how are we going to test that all our combinations work as we think > that > they are specified > are we understanding/specifying the combinations the same way as > anybody > else > > > I assume that many of you are wondering, as I do, if all this > flexibility > is really worth it's price. > Would the community not be better served by specifying profiles that are > a > complete-and-invariable combination of features and very small set of > numerical parameters? > > I would start with 2 profiles: > > the minimal profile (only basic features) > the maximum profile (all the features) > > and then (only if we are strongly convinced it is needed) add a middle > point. > > Please comment, > Julo > > > > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ips@ece.cmu.edu Sat Jun 23 16:57:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17323 for ; Sat, 23 Jun 2001 16:57:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5NIcpx19058 for ips-outgoing; Sat, 23 Jun 2001 14:38:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5NIcog19053 for ; Sat, 23 Jun 2001 14:38:50 -0400 (EDT) Received: from sdsl-216-36-75-164.dsl.sjc.megapath.net (HELO somesh) (216.36.75.164) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jun 2001 18:38:49 -0000 X-Apparently-From: Reply-To: From: "Somesh Gupta" To: , Subject: RE: profiles - a way to simplify iSCSI Date: Sat, 23 Jun 2001 11:30:09 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think we are just talking past each other so we should just let it rest. I understand what you are saying, and I still contend that if a reasonable profile that does not include all the features gets agreed upon, then the de-facto acceptance of that profile will make the features not included in the profile useless. We might as well try to take those things out of the first rev of the spec. > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Friday, June 22, 2001 9:09 PM > To: ips@ece.cmu.edu > Subject: RE: profiles - a way to simplify iSCSI > > > > > Somesh, > > You are still missing my point. Profiles are not proposed "in addition" to > what we have but instead of. > They are not meant to remove features that where introduced for a > legitimate reason or another but rather to limit > the variability in implementations and testing. > > Julo > > "Somesh Gupta" on 22-06-2001 21:16:33 > > Please respond to someshg@yahoo.com > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: RE: profiles - a way to simplify iSCSI > > > > > Julian, > > I think a number of our colleagues are speaking about the > complexity of the spec as it stands today and the need > to reduce the complexity. > > As I said, if a reasonable profile gets agreed upon (I apologise > in advance but I have not seen the ability to say no to feature > creep here), then that will become the de-facto standard. And > everything else will be an appendage. > > We might as well do that to start with. > > It is much better to do that, and as Steph suggested, add > features that are required in a newer rev of the spec. It is > not as if standards don't evolve. > > John Vrabel's message indicates a very good starting point > for pruning the spec (I disagree on the asynch messages). > > Somesh > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > julian_satran@il.ibm.com > > Sent: Friday, June 22, 2001 8:15 AM > > To: ips@ece.cmu.edu > > Subject: RE: profiles - a way to simplify iSCSI > > > > > > > > > > Robert, > > > > Profiles are meant INSTEAD -OF not in addition to the current set of > > features. > > I appreciate your concerns but I think that I must have misstated the > > profile intention. > > A profile will be an exact mapping of a set of functions we have today. > > As such it will be SIMPLER both to implement and test. > > > > Julo > > > > "Robert Griswold" on 22-06-2001 17:19:47 > > > > Please respond to "Robert Griswold" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: RE: profiles - a way to simplify iSCSI > > > > > > > > > > Julian: > > > > Well, drawing on my experience from the consumer storage specs > > (ATA/ATAPI/MMC), profiles and features lead to huge interoperability > > problems. The issue for robust (full featured) targets and initiators > > is they have to chase down every single interpretation of feature sets, > > some that they don't even care about, so the devices are not caught in > > transport or command sequences they have no idea about. I am in > > agreement with David Black and others who have specified that the iSCSI > > transport needs simplicity rather than complexity; I fear that providing > > still more optional implementations would lead to more problems. If we > > believe the hype from the press, then iSCSI will make for cheap targets, > > which means fast product schedules and low engineering and test coverage > > from companies that could ship millions of little iSCSI boxes. A > > tighter iSCSI specification might help keep some of these potential > > interoperability problems from becoming wildfires. > > > > Bob > > > > Robert Griswold > > Technologist > > Crossroads Systems, Inc. > > 512-928-7272 > > > > -----Original Message----- > > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] > > Sent: Thursday, June 21, 2001 12:15 PM > > To: ips@ece.cmu.edu > > Subject: profiles - a way to simplify iSCSI > > > > > > > > Dear colleagues, > > > > iSCSI keeps getting richer in negotiable parameters/features. > > Although flexibility is a great thing every new negotiable > > parameter/feature get us all worrying about: > > > > what it will break when used in combination with other > > parameters/features > > how are we going to test that all our combinations work as we think > > that > > they are specified > > are we understanding/specifying the combinations the same way as > > anybody > > else > > > > > > I assume that many of you are wondering, as I do, if all this > > flexibility > > is really worth it's price. > > Would the community not be better served by specifying profiles that are > > a > > complete-and-invariable combination of features and very small set of > > numerical parameters? > > > > I would start with 2 profiles: > > > > the minimal profile (only basic features) > > the maximum profile (all the features) > > > > and then (only if we are strongly convinced it is needed) add a middle > > point. > > > > Please comment, > > Julo > > > > > > > > > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ips@ece.cmu.edu Sat Jun 23 20:03:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19520 for ; Sat, 23 Jun 2001 20:03:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5NLXt728138 for ips-outgoing; Sat, 23 Jun 2001 17:33:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5NLXrg28134 for ; Sat, 23 Jun 2001 17:33:53 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id OAA11472 for ; Sat, 23 Jun 2001 14:33:44 -0700 (PDT) Received: from aimexc03.corp.adaptec.com (aimexc03.corp.adaptec.com [162.62.62.43]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id OAA14828 for ; Sat, 23 Jun 2001 14:11:15 -0700 (PDT) Received: by aimexc03.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Jun 2001 14:22:02 -0700 Message-ID: <268DBFF7D2A3D411A37400D0B72E345F03037C68@aimexc03.corp.adaptec.com> From: "Borison, Frankie" To: ips@ece.cmu.edu Subject: RE: profiles - a way to simplify iSCSI Date: Sat, 23 Jun 2001 14:21:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk How do I get off this mailing list??? -----Original Message----- From: Scott Bradner [mailto:sob@harvard.edu] Sent: Friday, June 22, 2001 4:13 PM To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI there seems to be a misunderstanding somewhere - I was trying to say nicely that a IPS protocol that has to have profiles would not pass the IESG but I guess I was too nice - I expect that teh IESG would return any such proposal to the WG for rework if such a proposal makes it to the IESG i.e the discussion in the followintg posting is not a productive path to be following Scott (one of the TSV area directors) ----- From owner-ips@ece.cmu.edu Fri Jun 22 17:05:13 2001 X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Date: Fri, 22 Jun 2001 15:59:06 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI References: <79CB6B56B942D411A9AB001083FCE91E10B509@san-exchange.dino> <3B33881A.D0568785@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Just noticed that we did not include descriptions for the columns in the spreadsheet. Here they are: 1st column - Section number of an internet-draft version of this spreadsheet, which we will generate if needed. 2nd column - Category; we divided up the different features into some categories that made sense to us. The first set is common to all iSCSI implementations; the second and third are for those features that apply just to targets or initiators. 3rd column - Feature; short description of each feature. 4th column - Reference; a reference to the section number of the iSCSI document that best describes the feature and its status. 5th column - Status. M = Mandatory O = Optional R = Recommended (we have none of these now) X = Prohibited (we have none of these, either) If numbers appear after the status, e.g. M:4.5, it means that the feature is mandatory if the feature numbered 4.5 is implemented. I just noticed that some of our numbers had changed, so a few of these might still be typos. 6th column - Value. This is used if the feature is more than just a check box; for instance, if an implementation supports "Data Digest - Other", it is used to indicate some reference to what "other" means. Hope this helps, Mark Mark Bakke wrote: > > We've been thinking about how to profile iSCSI implementations > as well, and Paul Congdon, Matthew Burbridge (both of HP) and > I have come up with a spreadsheet that sort of follows the PICS > pro-forma that the IEEE folks use. Anyway, it appears that this > might be a useful thing to start discussing. We have attempted > to list the major mandatory and optional features, but have not > had enough review time yet to guarantee that it exactly matches > the spec, so comments are welcome. > > Julian has placed it on his web page at: > > http://www.haifa.il.ibm.com/satran/ips/iSCSIv6_PICs-5.pdf > > I apologize that this is not in internet-draft form, or if this > list is not exactly the right place to do this. However, I think > that it will help show the sheer number of optional features we > are faced with, and may help us prioritize what must stay in the > protocol, and what we could live without in the interest of > simplicity. > > Hopefully, this will help. > > -- > Mark > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Sat Jun 23 22:44:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22563 for ; Sat, 23 Jun 2001 22:44:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5O0w9508581 for ips-outgoing; Sat, 23 Jun 2001 20:58:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5NNNPg03793 for ; Sat, 23 Jun 2001 19:23:25 -0400 (EDT) Received: from mikesdell7500 ([64.170.152.214]) by mta7.pltn13.pbi.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with SMTP id <0GFE00JTDOYXP3@mta7.pltn13.pbi.net> for ips@ece.cmu.edu; Sat, 23 Jun 2001 16:23:23 -0700 (PDT) Date: Sat, 23 Jun 2001 16:20:22 -0700 From: "Michael J. S. Smith (PacBell)" Subject: Re: profiles - a way to simplify iSCSI To: ips@ece.cmu.edu Cc: smithmjs@pacbell.net Reply-to: "Michael J. S. Smith (PacBell)" Message-id: <002401c0fc3b$136db200$6501a8c0@mikesdell7500> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 References: X-Priority: 3 Sender: owner-ips@ece.cmu.edu Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by ece.cmu.edu id f5O0w9608581 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA22563 I took the liberty of converting the PDF of the Bakke/Burbridge/Congdon iSCSI table to text using http://access.adobe.com/access_email.html, since I thought it useful to have this information archived. Here is the key to the columns again (from Mark's email): 1st column - Section number of an internet-draft version of this spreadsheet, which we will generate if needed. 2nd column - Category; we divided up the different features into some categories that made sense to us. The first set is common to all iSCSI implementations; the second and third are for those features that apply just to targets or initiators. 3rd column - Feature; short description of each feature. 4th column - Reference; a reference to the section number of the iSCSI document that best describes the feature and its status. 5th column - Status. M = Mandatory O = Optional R = Recommended (we have none of these now) X = Prohibited (we have none of these, either) If numbers appear after the status, e.g. M:4.5, it means that the feature is mandatory if the feature numbered 4.5 is implemented. I just noticed that some of our numbers had changed, so a few of these might still be typos. 6th column - Value. This is used if the feature is more than just a check box; for instance, if an implementation supports "Data Digest - Other", it is used to indicate some reference to what "other" means. I reproduce the conversion result below, exactly as I received it (so there are some page numbers included, for example). The text is quite readable and allowed me to easily see the sections marked optional and mandatory. I post this hoping others find it as useful as I do. Aloha Mike Smith *Pages 1--16 from þÿ* Authors: Mark Bakke, Matthew Burbridge, Paul Congdon 4 iSCSI Common Features Feature Reference Status Value 4.1 Access Control and Authorization 4.1.1 Support access control by iSCSI Initiator Name O 4.1.2 Supports access control by iSCSI Target Name O 4.2 iSCSI Data Integrity 4.2.1 Support Some Header Digest Scheme 8.1.3 M 4.2.2 Support Header Digest -None A. 01 M 4.2.3 Support Header Digest -CRC-32C A. 01 M 4.2.4 Support Header Digest -Other A. 01 O other method 4.2.5 Support Some Data Digest Scheme 8.1.3 M 4.2.6 Support Data Digest -None A. 01 M 4.2.7 Support Data Digest -CRC-32C A. 01 M 4.2.8 Support Data Digest -Other A. 01 O other method 4.3 PDU Formats 4.3.1 Support Additional Header Segment 2.2.3 O 4.3.2 Support Extended CDB 2.2.4 O 4.3.3 Support Bi-Directional Data Transfer 2.2.4 O 4.3.4 Set all undefined and reserved bits to zero 2 M 4.3.5 Set P/ F bit to 0 on PDUs where it is not used 2.2.2.4 M 4.3.6 Uses LUN field for other purpose 2.2.2.7 O purpose 4.3.7 Task tags are unique over session 2.2.2.8 M 4.4 Data Transfer Mechanism 4.4.1 Support Unsolicited Data 1.2.5 O 4.4.2 Support Immediate Data 1.2.5 O 1 4.4.3 Support Bi-directional data 2.3.5,2.7.7 O 4.4.4 Support piggybacking of status in Final Data PDU 2.7.7 O 4.4.6 Ready to Transfer (Data Flow) 2.17 M 4.4.7 Deliver commands in CmdSN order 1.2.2.1 M 4.4.8 Support DataSN 1.2.2.3 M 4.4.9 Support Response Numbering (StatSN) 1.2.2.2 M 4.4.10 Use same StatSN on retried responses as original PDU 2.4.8 M 4.4.11 Non-immediate commands always use CmdSN values between ExpCmdSN and MaxCmdSN 1.2.2.1 M 4.4.12 (target) Silently ignors commands outside CmdSN range or duplicates within range that don't have X-bit set 1.2.2.1 M 4.4.13 (target) Never issues more than 2^ 32-1 R2Ts for any given write command 1.2.2.3 M 4.4.14 Set F-bit= 1 when Expected Data Transfer Length and length of immediate data are the same 2.3.5 M 4.4.15 (target) Support and enable autosense 2.4.5 M 4.4.16 When target transfer tag is provided, LUN field is valid and same as original command 2.7.2 M 4.4.17 Only include StatSN when S-bit= 1 2.7.2 M 4.4.18 (target) Returns data in increasing buffer offset order when EMDP mode is selected 2.7.5 M 2 4.4.19 (initiator) Delivers all data within a burst in increasing buffer offset order 2.7.5 M 4.4.20 (target) Upon successful completion, returns status in last SCSI Data Packet 2.7.7 O 4.4.21 (target) If command completes with an error, response and status is sent is SCSI Response PDU 2.7.7 M 4.4.22 (target) Requests chunks of data from initiator using R2T in any order 2.17.3 O 4.5 Sync & Steering 4.5.1 Support Sync & Steering 1.2.8 O 4.5.2 Retain buffer offsets and end addresses of each iSCSI PDU 1.2.8.2 M: 4.6 4.5.3 Include steering information in PDU independent of other layers 1.2.8.2 M: 4.6 4.5.4 Map outgoing stream addresses to TCP stream sequence numbers 1.2.8.2 M: 4.6 4.5.5 Restricts certain transformations by Upper Functional Layers 1.2.8.3 O 4.5.6 Use Marker Protocol for Sync and Steering D. 00 O 4.5.7 Markers indicate the offset to a 4- byte word boundary D. 06 M: 4.5.6 4.6 MIB Support 4.6.1 Support iSCSI MIB MIB M 4.7 Lower Layer Protocol Features [e. g. IPSec, Keep Alive, Data Integrity] 4.7.1 Use TCP keep-alive option to enable early link failure detection 6.5 O 4.7.2 Support graceful connection shutdown by sending TCP FINs once there are no outstanding tasks with allegiance to the connection 1.2.6 M 3 4.7.3 Respond to TCP FINs by closing target half of connection after concluding all outstanding commands and sending status 1.2.6 O 4.7.4 Use IPSec for Data Integrity O 4.8 Discovery [e. g. Send Targets support, SLP, etc] 4.8.1 Supports/ Uses SendTargets command O 4.8.2 Supports/ Uses SLP O 4.8.3 Supports other discovery mechanism O other mechanism 4.8.4 Sends/ Uses async messages for new targets O 4.8.5 Sends/ Uses async messages for new LUNs O 4.9 Naming [e. g. scope of iSCSI name (per port or per device]] 4.9.1 Supports manufacterer-named iSCSI name (may be based on user configuration) M naming authority 4.9.2 Supports user-configurable iSCSI name( s) O 4.9.3 Generates names with Unicode characters O 4.9.4 Supports user-configurable iSCSI alias( es) O 4.9.5 Full Unicode Support (names & aliases can be configured using Unicode) O 4.9.6 Unicode Comparison Support (names using Unicode can be compared) M 4.9.7 (initiator) Supports common iSCSI name across NIC/ HBA interfaces 4 4.9.8 (initiator) NIC/ HBA iSCSI name settable via API 4.9.9 (initiator) NIC/ HBA ISID range settable via API 4.9.10 Support IPv4 Address Format 1.2.7 M 4.9.11 Support Fully Qualified DNS names 1.2.7 O 4.9.12 Support/ Use Port field in TargetAddress 1.2.7 O 4.10 Text Mode Negotiation 4.10.1 Use keyword "none" to indicate missing function 1.2.4 M 4.10.2 Returns keyword "none" 1.2.4 O 4.10.3 Use keyword "reject" to indicate unsupported or unallowed options 1.2.4 O 4.10.4 (initiator) Uses same Initiator Task Tag on all Text commands sent as part of a negotiation sequence 2.8.2 M 4.10.5 Negotiates operation parameters outside of login phase 4, 4.3 O 4.10.6 When using security, negotiate all other iSCSI parameters after security is established 4.2 O? 4.10.7 (initiator) Negotiates proprietary options 4.2 O values 4.10.8 Terminate text negotiation during login with Login Response with F-bit= 1 4.3 M 5 iSCSI Target Features Feature Reference Status Value 5.1 Login Features Supported 5.1.1 Require Initiator name during login 1.2.7 M 5.1.2 Require Target name during login 1.2.7 M 5.1.3 Send Target Alias during login O 5.1.4 Never sets F-bit= 1 when status is "accept login" and login command had F-bit= 0 2.11.4 M 5 5.1.5 Sets F-bity when login negoiation is complete M 5.1.6 Support Partial Login Response M 5.1.7 5.2 Authentication Methods Supported. 5.2.1 Support some authentication method B. 01 M 5.2.2 Support authentication method - None B. 01 M 5.2.3 Support authentication method - CHAP B. 01 O 5.2.4 Support authentication method -SRP B. 01 M 5.2.5 Support authentication method - Kerberos5 B. 01 O 5.2.6 Support authentication method - SPKM-1/ 2 B. 01 O 5.2.7 Support authentication method - Other B. 01 O other method 5.2.8 Support authentication via Ipsec B. 01 5.3 Asynchronous Message Used 5.3.1 Send Async-event to initiators when target is reset 2.18.1 O 5.3.2 Send Async-event to initiators to request logout 2.18.1 O 5.3.3 Send Async-event to initiators to notify connection drop 2.18.1 O 5.3.4 Send Async-event to initiators to notify all connections dropped 2.18.1 O 5.3.5 Send Async-event to initiators to notify session termination 2.18.1 O 5.4 Error Handling 5.4.1 Error Detection 5.4.1.1 Format Errors Detection 6.1 M 6 5.4.1.2 Digest Error Detection 6.2 M 5.4.1.3 Sequence Error Detection 6.3 M 5.4.1.4 Protocol Error Detection 6.4 M 5.4.1.4.1 Detect protocol error if PDU other than login or text is received before full feature phase 1.2.3 M 5.4.1.5 Error Detection via NOP-ins 2.12 O 5.4.1.6 Send Reject PDU on header digest 2.20 M 5.4.1.7 Send Reject PDU on data digest 2.20 M 5.4.1.8 Send Reject PDU on protocol error 1.2.3 O 5.4.2 Error Recovery Features Supported 5.4.2.1 Negotiation Recovery 6.7.4 M 5.4.2.2 Issue R2T for error recovery 2.17 O 5.4.2.3 Accept Command with X Bit set 2.2.2.1 O 5.4.2.4 Reject Command with X Bit set 2.2.2.1 O 5.4.2.5 Issue NOP-in to recover Status 2.13,1.2.2 O 5.4.2.6 Issue NOP-in recovery to Data/ Cmds 2.13 O 5.4.2.7 Issue Status PDU if SNACK-Status received 2.16 O 5.4.2.8 Issue Data PDU if SNACK-Data received 2.16 O 5.4.2.9 Issue R2T PDU if SNACK-R2T received 2.16 O 5.4.2.10 Issue Reject if SNACK-Data received 2.16 O 5.4.2.11 Issue Reject if SNACK-R2T received 2.16 O 5.4.2.12 Issue Async on connection termination 2.18.1 O 5.4.2.13 Issue Async on session termination 2.18.1 O 7 5.5 Session Aggregation Used [e. g. Connection Aggregation, Multiple Sessions, Session Spanning] 5.5.1 Support use of common aggregation tag in different TargetAddress fields of SendTargets response NDT M: 5.5.1 5.5.2 Support Multiple Session per Target 5.5.3 Support Multiple Targets 5.5.4 Support Multiple Service Portals 5.5.5 Support multiple sessions from same initiator O 5.5.6 Support connection allegience 1.2.5 M 5.5.7 Supports linked commands spanned over multiple connections 1.2.5 O 5.5.8 Supports interleaved unrelated SCSI commands over session 1.2.5 O 5.5.9 Support opening multiple connections for purpose of clean-up (I. e. non-full feature phase) 2.10.1 O 5.5.10 Ignores iSCSI Target name on login of additional connections 4.1 O 5.5.11 Issues Async message to request removal of connection from session 5.6 Reboot Behaviour [e. g. Use of Asynchronous Messages] 5.6.1 Sends async message when about to reboot, shut down, or fail over to another device 8 5.7 Session Management Features Supported [e. g. Includes features such as whether the target sends Redirect status] 5.7.1 Returns "Target Moved Temporarily" 2.11.4 O 5.7.2 Returns "Target Moved Permanently" 2.11.4 O 5.7.3 Returns "Proxy Required" 2.11.4 O 5.7.4 Returns "Target Removed" 2.11.4 O 5.7.5 Returns "Target Conflict" 2.11.4 O 5.7.6 Closes connection specified in CID after logout 2.15 M 5.7.7 Duplicates up to first 4096 bytes of data in NOP-Out 2.13 O 5.7.8 When initiating a NOP-In, initiator tag = 0xffffffff and target tag != 0xffffffff 2.13.1 M 5.7.9 Valid LUN field is included when P-bit= 1 2.13.3 M 5.8 iSCSI Task Management 5.8.1 Returns Initiator Task Tag in all SCSI Task Management responses 2.5.1 M 5.8.2 On Clear Task Set, enters a Unit Attention Condition for all other attached initiators 2.5.1 M 5.8.3 On Target Warm Reset and Target Cold Reset, enters a Unit Attention Condition for all attached initiators 2.5.1, 2.6.1 M 5.8.4 On Target Cold Reset, terminates all TCP conections to all initiators 2.5.1, 2.6.1 M 9 5.8.5 On Target Warm Reset, enters ACA state on all sessions and LUs where Unit Attention was reported when enabled by EnableACA 2.5.1 M 6 iSCSI Initiator Features Feature Reference Status Value 6.1 Login Features Supported 6.1.1 Send Initiator name during login 1.2.7 M 6.1.2 Send Target name during login 1.2.7 M 6.1.3 Send Initiator Alias during login O 6.1.4 Sets F-bit when login negoiation is complete M 6.1.5 Accept Partial Login Response M 6.1.6 Support authentication method - None B. 01 M 6.1.7 Support authentication method - CHAP B. 01 O 6.1.8 Support authentication method -SRP B. 01 M 6.1.9 Support authentication method - Kerberos5 B. 01 O 6.1.10 Support authentication method - SPKM-1/ 2 B. 01 O 6.1.11 Support authentication method - Other B. 01 O other method 6.1.12 Support authentication via Ipsec B. 01 6.1.13 Supports authenticating target 1.2.3 O 6.1.14 Never issues a Login Command more than once on same TCP connection 2.10 M 6.3 Asynchronous Message Support 6.3.1 Handle Async-event to initiators when target is reset 2.18.1 O 10 6.3.2 Handle Async-event to initiators to request logout 2.18.1 O 6.3.3 Handle Async-event to initiators to notify connection drop 2.18.1 O 6.3.4 Handle Async-event to initiators to notify all connections dropped 2.18.1 O 6.3.5 Handle Async-event to initiators to notify session termination 2.18.1 O 6.4 Error Handling 6.4.1 Error Detection 6.4.1.1 Format Errors Detection 6.1 M 6.4.1.2 Digest Error Detection 6.2 M 6.4.1.3 Sequence Error Detection 6.3 M 6.4.1.4 Protocol Error Detection 6.4 M 6.4.1.6 Error Detection via NOP-outs 6.4.2.2 Recovery Within-connection 6.7.2 O 6.4.2.3 Recovery Within-session 6.7.3 O 6.4.2.4 Negotiation Recovery (To be renamed) 6.7.4 M 6.4.2.5 Session Recovery 6.7.5 O 6.4.2.6 Accept R2T for error recovery 2.17 O 6.4.2.7 Issue SNACK Request (for Status) 2.16 O 6.4.2.8 Issue SNACK Request (for Data) 2.16 O 6.4.2.9 Issue SNACK Request (for R2T) 2.16 O 6.4.2.10 Issue Command with X Bit set 2.2.2.1 O 6.4.2.11 Accept NOP-in to recover Status 2.13 O 6.4.2.12 Accept NOP-in recovery to Data/ Cmds 2.13 O 6.4.2.13 Resend Data PDU if SACK received 6.3 O 6.5 Session Aggregation Used [e. g. Connection Aggregation, Multiple Sessions, Session Spanning] 6.5.1 Supports single session to span multiple TCP connections O 11 6.5.2 Supports single session to span multiple TCP addresses O 6.5.3 Support use of aggregation tag in SendTargets response M: 5.5 6.5.4 Support use of common aggregation tag in different TargetAddress fields of SendTargets response M: 5.5.1 6.5.5 Creates multiple sessions to same target O 6.5.6 Support connection allegience 1.2.5 M 6.5.7 Sends linked commands over multiple connections 1.2.5 O 6.5.8 Interleaves unrelated SCSI commands over session 1.2.5 O 6.5.9 Supports opening multiple connections for purpose of clean-up (I. e. non-full feature phase) 2.10.1 O 6.5.10 Uses ISID and TSID of existing session during login on connections to be added to same session 2.10.6 M: 6.5 6.5.11 Uses Logout command to remove a connection from a session 2.14 O 6.5.12 Closes connection specified in CID after logout 2.15 M 6.5.13 Does NOT specify the following text parameter on login over new connections to existing sessions: MaxConnections, TargetName, InitiatorName, DataOrder E. 0 M 6.6 Reboot Behaviour [e. g. Use of Logout] 6.6.1 Sends logout command to targets during shutdown or reboot O? 6.6.2 Logs out of target when idle O 12 6.7 Session Management Features Supported [e. g. Login/ Logout Including Handling of the various status code] 6.7.1 Closes connection specified in CID after logout 2.15 M 6.7.2 Uses immediate delivery for NOP-Out 2.12 O 6.7.3 Uses in-order delivery for NOP-Out 2.12 O 6.7.4 Include Initiator Tag when P-bit= 1 2.12.2 M 6.7.5 Returns Target Tag in response to NOP-In 2.12.3 M 6.7.6 Includes valid LUN field when Target Tag is set 2.12.3 M 6.7.7 Sends less than 4096 bytes of data 2.12.4 O 6.8 iSCSI Task Management 6.8.1 Uses Abort Task 2.5.1 O 6.8.2 Uses Abort Task Set 2.5.1 O 6.8.3 Uses Clear ACA 2.5.1 O 6.8.4 Uses Clear Task Set 2.5.1 O 6.8.5 Uses Logical Unit Reset 2.5.1 O 6.8.6 Uses Target Warm Reset 2.5.1 O 6.8.7 Uses Target Cold Reset 2.5.1 O 7 Target iSCSI Maximum and Minimum Values Min Max 7.1 Number of Sessions 7.2 Number of Sessions Per Target 7.3 Number of Sessions Per Initiator 7.4 Number of Targets 7.5 Number of Service Ports Per Device 7.6 Text Command Size 7.7 Text Value Size 7.8 NOP-in Data Size 13 7.9 NOP-out Data Size 7.10 Within-task Recovery Timeout 8 Initiator iSCSI Maximum and Minimum Values Min Max 8.1 Number of Sessions 8.2 Number of Sessions Per Target 8.3 Number of Targets 8.4 Number of Service Ports Per Device 8.5 Text Command Size 8.6 Text Value Size 8.7 NOP-in Data Size 8.8 NOP-out Data Size 8.9 Within-task Recovery Timeout 8.10 9 Target Text Parameters Reference Status Value/ Range 9.1 MaxConnections E-08 O 9.2 TargetName E-09 O 9.3 InitiatorName E-10 O 9.4 TargetAlias E-11 O 9.5 InitiatorAlias E-12 O 9.6.1 TargetAddress (DNS) E-13 O 9.6.2 TargetAddress (IPv4) E-13 O 9.7 SendTargets E-14 O 9.8 AccessID E-15 O 9.9 FMarker E-16 O 9.10 RFMarkInt E-17 O 9.11 SFMarkInt E-18 O 9.12 IFMarkInt E-19 O 9.13 InitialR2T E-20 O 9.14 BidiInitialR2T E-21 O 9.15 ImmediateData E-22 O 9.16 DataPDULength( Data Digests on) E-23 O 9.17 DataPDULength( Data Digests off) E-24 O 9.18 FirstBurstSize E-25 O 14 9.19 LogoutLoginMinTime E-26 O 9.20 LogoutLoginMaxTime E-27 O 9.21 EnableACA E-28 O 9.22 MaxOutstandingR2T E-29 O 9.23 DataOrder E-30 O 9.24 BootSession E-31 O 9.25 The Glen-Turner Vendor Specific Key E-32 O 10 Initiator Text Parameters Reference Status Value/ Range 10.1 MaxConnections E-08 O 10.2 TargetName E-09 O 10.3 InitiatorName E-10 O 10.4 TargetAlias E-11 O 10.5 InitiatorAlias E-12 O 10.6.1 TargetAddress (DNS) E-13 O 10.6.2 TargetAddress (IPv4) E-13 O 10.7 SendTargets E-14 O 10.8 AccessID E-15 O 10.9 FMarker E-16 O 10.10 RFMarkInt E-17 O 10.11 SFMarkInt E-18 O 10.12 IFMarkInt E-19 O 10.13 InitialR2T E-20 O 10.14 BidiInitialR2T E-21 O 10.15 ImmediateData E-22 O 10.16 DataPDULength( Data Digests on) E-23 O 10.17 DataPDULength( Data Digests off) E-24 O 10.18 FirstBurstSize E-25 O 10.19 LogoutLoginMinTime E-26 O 10.20 LogoutLoginMaxTime E-27 O 10.21 EnableACA E-28 O 10.22 MaxOutstandingR2T E-29 O 10.23 DataOrder E-30 O 10.24 BootSession E-31 O 10.25 The Glen-Turner Vendor Specific Key E-32 O 15 16 From owner-ips@ece.cmu.edu Mon Jun 25 04:04:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08522 for ; Mon, 25 Jun 2001 04:04:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5P6F1519303 for ips-outgoing; Mon, 25 Jun 2001 02:15:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5P6Exg19295 for ; Mon, 25 Jun 2001 02:14:59 -0400 (EDT) Received: from ahganemw2k (sj-dial-4-79.cisco.com [171.68.181.208]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id CAA09733 for ; Mon, 25 Jun 2001 02:14:52 -0400 (EDT) From: "Ayman Ghanem" To: Subject: iSCSI: Version number for Plugfest Date: Mon, 25 Jun 2001 01:13:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Regarding the upcoming iSCSI interoperability plugfest, I want to clarify that the version number to be used for the login min/max version is 0x01/0x01 (as in draft-06) as opposed to the draft version (06/06). -Ayman From owner-ips@ece.cmu.edu Mon Jun 25 04:04:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08539 for ; Mon, 25 Jun 2001 04:04:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5P6GEU19404 for ips-outgoing; Mon, 25 Jun 2001 02:16:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from internaut.com ([64.38.134.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5P6GCg19400 for ; Mon, 25 Jun 2001 02:16:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA18395; Sun, 24 Jun 2001 23:09:34 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sun, 24 Jun 2001 23:09:34 -0700 (PDT) From: Bernard Aboba To: julian_satran@il.ibm.com cc: ips@ece.cmu.edu Subject: RE: profiles - a way to simplify iSCSI In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > You are still missing my point. Profiles are not proposed "in addition" to > what we have but instead of. > They are not meant to remove features that where introduced for a > legitimate reason or another but rather to limit > the variability in implementations and testing. > The best way to limit the variability in implementations and testing is not to include so many "features" in the first place. It's often tempting to resolve potential conflicts by turning out a "kitchen sink spec" but that's almost always a worse choice than choosing between one of the alternatives. Similarly, options are a losing proposition because you have to implement them because someone else might, but you can't guarantee they'll be used. So if something doesn't make it into what would have been the "profile" I'd question why it can't be thrown out altogether. As part of the Draft Standards application, "features" not proven to interoperate with independent implementations have to be removed. So if a "feature" was inserted merely to keep the peace, has problematic interoperability or is not on the slate to be independently implemented, we might as well toss it out. "There's never a better time to weed a garden than RIGHT NOW." From owner-ips@ece.cmu.edu Mon Jun 25 11:29:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18250 for ; Mon, 25 Jun 2001 11:29:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5PE7DS26216 for ips-outgoing; Mon, 25 Jun 2001 10:07:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com ([216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5PE7Cg26210 for ; Mon, 25 Jun 2001 10:07:12 -0400 (EDT) To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI In-Reply-To: Message from Bernard Aboba of "Sun, 24 Jun 2001 23:09:34 PDT." References: Date: Mon, 25 Jun 2001 10:06:42 -0400 From: Stephen Bailey Message-Id: <20010625140655.B99D24E8D@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk > Similarly, options are a losing proposition because you have > to implement them because someone else might I thought you didn't have to implement them because it's certain that someone else won't :^) Steph From owner-ips@ece.cmu.edu Mon Jun 25 11:42:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18741 for ; Mon, 25 Jun 2001 11:42:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5PDTRZ23562 for ips-outgoing; Mon, 25 Jun 2001 09:29:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5PDTQg23558 for ; Mon, 25 Jun 2001 09:29:26 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA00571 for ; Mon, 25 Jun 2001 09:29:20 -0400 (EDT) Message-ID: <3B373BAA.AF7B0C95@cisco.com> Date: Mon, 25 Jun 2001 08:24:58 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: MIB Draft-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The new MIB has seen some significant changes. Most notably, it is much smaller. You need not be afraid to read it any longer. Here are the modifications: 1. The object model has remained mostly the same, with the exception that we have changed the target listen port to a target portal, and have added an initiator portal. 2. Counters have been significantly pruned, from 254 down to 23. 3. Descriptions have been updated. 4. All of the IpAddress-type attributes have been changed to support either IPv4 or v6 addresses. 5. TCP port attributes have been renamed to support any upper-level transport protocol that iSCSI may later define. 6. iscsiCxnState enums have been defined. 7. Attributes on the "last failure" to occur have been added to the initiator and target objects, for use with notifications (traps). 8. Two notifications have been added - one for initiator-detected problems; the other for target-detected problems. Julian has made the draft available on his web site at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-mib-01.txt Please send any comments on the MIB by 7/xx; we plan to publish the next version (with comments and draft-07 updates) by 7/18, for the August IETF meeting. Here are a few things in particular we'd like feedback on: 1. The IscsiSessionCxnErrorStatsTable is currently within the session, but in many implementations, the session will be destroyed as soon as one of these errors are counted. Should this be moved to the target and initiator tables instead? 2. As soon as we clean up the SendTargets aggregation tag discussion, we will add a similar attribute to TargetPortal. 3. We used to have two authmethods in the SessionAttributes table for initiator and target. These were removed after the -06 discussion of having them be symmetrical. We'll put in whatever is appropriate when this has been resolved. 4. Would it be useful to a management station to be able to see the InitiatorAlias or TargetAlias of the "other side" of a session? If so, we can add it. 5. We have most of the current negotiated attributes in the SessionAttributes table; should we be complete with these, or is there just a subset of these that is really useful for a management station to look at? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jun 25 14:23:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23275 for ; Mon, 25 Jun 2001 14:23:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5PGRFs06672 for ips-outgoing; Mon, 25 Jun 2001 12:27:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5PEprg29408 for ; Mon, 25 Jun 2001 10:51:53 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA269272 for ; Mon, 25 Jun 2001 16:51:46 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5PEpko34054 for ; Mon, 25 Jun 2001 16:51:46 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A76.00517562 ; Mon, 25 Jun 2001 16:49:44 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Mon, 25 Jun 2001 17:45:26 +0300 Subject: RE: profiles - a way to simplify iSCSI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, I understand you well stated (and well intentioned remarks) and it is hard not too agree with motherhood statements. However I have to mention that most of the features where added with care and only a very few remained after selection. Peace was not what we had in mind - but you can't outright reject feature that have a clearer rationale for a class of users. However the draft addresses a wide spectrum of devices with different requirements (as do most of the SCSI drafts). Some can be met only with minimal requirement (most low-end and office raid-boxes) while others require higher performance/reliability/maintainability etc. Profiles could clearly cluster the space and simplify implementation and testing. Regards, Julo Bernard Aboba on 25-06-2001 09:09:34 Please respond to Bernard Aboba To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: profiles - a way to simplify iSCSI > You are still missing my point. Profiles are not proposed "in addition" to > what we have but instead of. > They are not meant to remove features that where introduced for a > legitimate reason or another but rather to limit > the variability in implementations and testing. > The best way to limit the variability in implementations and testing is not to include so many "features" in the first place. It's often tempting to resolve potential conflicts by turning out a "kitchen sink spec" but that's almost always a worse choice than choosing between one of the alternatives. Similarly, options are a losing proposition because you have to implement them because someone else might, but you can't guarantee they'll be used. So if something doesn't make it into what would have been the "profile" I'd question why it can't be thrown out altogether. As part of the Draft Standards application, "features" not proven to interoperate with independent implementations have to be removed. So if a "feature" was inserted merely to keep the peace, has problematic interoperability or is not on the slate to be independently implemented, we might as well toss it out. "There's never a better time to weed a garden than RIGHT NOW." From owner-ips@ece.cmu.edu Mon Jun 25 15:05:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24374 for ; Mon, 25 Jun 2001 15:05:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5PH6HZ09528 for ips-outgoing; Mon, 25 Jun 2001 13:06:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5PH6Fg09515 for ; Mon, 25 Jun 2001 13:06:15 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA37678 for ; Mon, 25 Jun 2001 12:58:22 -0400 Received: from f3n41e (d03nm041h.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5PH6D0244768 for ; Mon, 25 Jun 2001 11:06:13 -0600 Importance: Normal Subject: iSCSI: Large Data Block Handling To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Kaladhar Voruganti" Date: Mon, 25 Jun 2001 18:06:10 +0100 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/25/2001 10:06:13 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I would like some opinions on the following issue: When the initiator and the target negotiate an agreed upon PDU max size (say 8K), and if the initiator receives a larger sized read request (say 64K), then a) Should the initiator chop the large 64K size request into smaller 8K sized requests and send these to the target OR b) The initiator sends the 64K request to the target and the target sends only 8K responses to the initiator. Kaladhar From owner-ips@ece.cmu.edu Mon Jun 25 15:12:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24487 for ; Mon, 25 Jun 2001 15:12:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5PHsEr13109 for ips-outgoing; Mon, 25 Jun 2001 13:54:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5PHsCg13105 for ; Mon, 25 Jun 2001 13:54:12 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Jun 25 13:52:42 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Mon Jun 25 13:53:10 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id NAA08037; Mon, 25 Jun 2001 13:52:52 -0400 (EDT) Date: Mon, 25 Jun 2001 13:52:52 -0400 (EDT) Message-Id: <200106251752.NAA08037@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu, kaladhar@us.ibm.com Subject: Re: iSCSI: Large Data Block Handling Sender: owner-ips@ece.cmu.edu Precedence: bulk it should be (b). The iSCSI (i.e.transport) PDU size is not related to the SCSI request length. -sandeep > I would like some opinions on the following issue: > > When the initiator and the target negotiate an agreed upon PDU max size > (say 8K), and if the initiator receives a larger sized read request (say > 64K), then > > a) Should the initiator chop the large 64K size request into smaller 8K > sized requests and send these to the target > > OR > > b) The initiator sends the 64K request to the target and the target sends > only 8K responses to the initiator. > > > > Kaladhar From owner-ips@ece.cmu.edu Mon Jun 25 16:53:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26753 for ; Mon, 25 Jun 2001 16:53:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5PIocZ17393 for ips-outgoing; Mon, 25 Jun 2001 14:50:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5PIobg17389 for ; Mon, 25 Jun 2001 14:50:37 -0400 (EDT) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id DCA286E0; Mon, 25 Jun 2001 11:50:18 -0700 (PDT) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id C952A735; Mon, 25 Jun 2001 11:50:13 -0700 (PDT) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 25 Jun 2001 13:50:10 -0500 Message-ID: <31891B757C09184BBFEC5275F85D5595104D83@cceexc18.americas.cpqcorp.net> From: "Martin, Nick" To: "'sandeepj@research.bell-labs.com'" , ips@ece.cmu.edu, kaladhar@us.ibm.com Subject: RE: iSCSI: Large Data Block Handling Date: Mon, 25 Jun 2001 13:49:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk To emphasize Sandeep's point. iSCSI PDU size does not limit the amount of data which can be transferred with a single SCSI CDB. However, both the initiator and the target must respect DataPDULength on all PDU's. If the current negotiated value is 8K then the initiator must break up write data and the target must break up read data into multiple PDU's each carrying no more than 8K of data. The target also is allowed to request more than 8K of write data with a single R2T, but the data is expected to be delivered by multiple PDU's whenever required. Thanks, Nick -----Original Message----- From: sandeepj@research.bell-labs.com [mailto:sandeepj@research.bell-labs.com] Sent: Monday, June 25, 2001 12:53 PM To: ips@ece.cmu.edu; kaladhar@us.ibm.com Subject: Re: iSCSI: Large Data Block Handling it should be (b). The iSCSI (i.e.transport) PDU size is not related to the SCSI request length. -sandeep > I would like some opinions on the following issue: > > When the initiator and the target negotiate an agreed upon PDU max size > (say 8K), and if the initiator receives a larger sized read request (say > 64K), then > > a) Should the initiator chop the large 64K size request into smaller 8K > sized requests and send these to the target > > OR > > b) The initiator sends the 64K request to the target and the target sends > only 8K responses to the initiator. > > > > Kaladhar From owner-ips@ece.cmu.edu Mon Jun 25 18:31:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28639 for ; Mon, 25 Jun 2001 18:30:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5PKbSh25321 for ips-outgoing; Mon, 25 Jun 2001 16:37:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5PKbPg25316 for ; Mon, 25 Jun 2001 16:37:25 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel1.hp.com (Postfix) with ESMTP id 042561AB1; Mon, 25 Jun 2001 13:37:49 -0700 (PDT) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay2.corp.hp.com (Postfix) with ESMTP id C285C1F51C; Mon, 25 Jun 2001 13:36:42 -0700 (PDT) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 13:37:20 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09147@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Black_David@emc.com'" , mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Mon, 25 Jun 2001 13:37:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > Restricting SendTargets to only describe targets > accessible through the > on which it was issued prevents X from returning > information about Y and Z. It also prevents > X from returning information about targets on > X that are only accessible through other IP > addresses and/or TCP ports. I don't see the value of this restriction. One method to implement an iSCSI solution might use a configuration utility to specify a list of IP addresses representing separate targets (minimal configuration information), and then expect that a SendTargets command issued to the "iSCSI" target at these IP addresses to allow discovery of all IP addresses and accessable targets that are a part of the reporting iSCSI implementation. If duplicate target information is 'discovered', it can be reconciled by comparing target names. The rules you've outlined would preclude this? > This forces > more pairs to be > discovered prior to issuing Send Targets. How? > > That may be a good thing - for example it makes > it possible for a management tool to figure out > where all of some Initiator's storage is without > ever issuing any SendTarget commands. That might be 'nice', but not mandatory. > It would > be a "bad thing" if the only way to find Y was > to issue a SendTargets to X (e.g., simple > mistake in configuring X can hide Y from > the management tool, even if all the Initiators > still work). This argument is somewhat less > compelling when we're dealing with two ports > on X instead of X and Y. I wouldn't necessarily advocate such a solution, but it's implementation dependant. We MUST NOT dictate implementation. > > "same canonical target" was an attempt to deal > with the "It also prevents ..." sentence above. > The concern I have is about someone placing > information about X, Y, and Z on all of X, Y, > and Z, and then claiming that the "iscsi" > canonical target on X, Y, and Z is the same > target because the same information is returned > in each case. This seems to make the "same > " approach preferable. I don't see your concern here. The "iSCSI" target name is not unique, does not represent a fully functional target, and MUST NOT be compared to determine 'target identity'. That seems clear. If different IP addresses report the same information via SendTargets, the initiator's functional sessions will be to the reported. What's the harm? I'm not advocating this approach, but if implemented correctly, it should work. When we talk about SendTargets "returning a list of targets", we are mostly thinking about the notion that a single iSCSI target node might chose to export different capabilities (LUN maps, features?) by exporting multiple target names. I'm not sure anyone envisioned the scenario you outline, but I don't see any real issues with it. > > Do you see a > need for a SendTargets issued to system X to > return information about system Y? No, but I see no reason to prohibit this. -Marj From owner-ips@ece.cmu.edu Mon Jun 25 20:33:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00774 for ; Mon, 25 Jun 2001 20:33:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5PMXIg03511 for ips-outgoing; Mon, 25 Jun 2001 18:33:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.6.9.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5PMXGg03506 for ; Mon, 25 Jun 2001 18:33:17 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E564C1A90 for ; Mon, 25 Jun 2001 16:33:15 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 7D472135 for ; Mon, 25 Jun 2001 16:33:15 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id PAA06549 for ; Mon, 25 Jun 2001 15:33:14 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA4226 for ; Mon, 25 Jun 2001 15:33:12 -0700 Message-ID: <3B37B46B.702F762@agilent.com> Date: Mon, 25 Jun 2001 15:00:11 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: All text keys MUST be supported? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit julian_satran@il.ibm.com wrote: > > 1.2.4 reads now: > > 1.1.1 Text Mode Negotiation > > During login and thereafter some session or connection parameters are > negotiated through an exchange of textual information. > > In "list" negotiation, the offering party sends a list of values for a > key in its order of preference. > > The responding party answers with the first value from the list it > supports and is allowed to use for the specific initiator. > > The value "none" MUST always be used to indicate a missing function. > However, none is a valid selection only if it is explicitly offered and > MAY be selected by omission (i.e., =none MAY be omitted). Why MAY "=none" be selected by omission? This is just another one of those "options" that we all hate. If it's none, explicitely say so. You also need to remove the "none MUST always be used to indicate a missing function" because the following paragraph allows the use of "reject" or "NotUnderstood" to indicate a missing function. These two paragraphs need cleaning up. > > If a target is not supporting, or not allowed to use with a specific > initiator, any of the offered options, it may use the value "reject". > The values "none" and "reject" are reserved and must be used only as > described here. Any key not understood is answered with > "NotUnderstood". > > The general format of text negotiation is: > > Offer-> =,,..., > Answer-> =|reject|NotUnderstood > > In "numerical" negotiations, the offering and responding party state a > numerical value. The result of the negotiation is key dependent; > frequently the lower or the higher of the two values is used. > > Although the initiator is the requesting party and controls the > request-response initiation and termination the target can offer > key=value pairs of its own as part of a sequence and not only in > response to an identical key=value pair offered by the initiator. > > And 2.8.3 reads: > > 1.1.1 Text > > The initiator sends the target a set of key=value or key=list pairs > encoded in UTF-8 Unicode. The key and value are separated by a '=' > (0x3D) delimiter. Many key=value pairs can be included in the Text block > by separating them with null (0x00) delimiters. A list is a set of > values separated by comma (0x2C). Large binary items can be encoded > using their hexadecimal representation (e.g., 8190 is 0x1FFE) or decimal > representation. The maximum length of an individual value (not its > string representation) is 255 bytes. > > The data length of a text command or response SHOULD be less than 4096 > bytes. Key names MUST NOT exceed 64 bytes. Key values MUST NOT exceed > 255 characters. data length should be less than PDUlength. -Matt From owner-ips@ece.cmu.edu Mon Jun 25 22:50:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05114 for ; Mon, 25 Jun 2001 22:50:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5Q0qch11611 for ips-outgoing; Mon, 25 Jun 2001 20:52:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5Q0qag11607 for ; Mon, 25 Jun 2001 20:52:37 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel2.hp.com (Postfix) with ESMTP id 3A14C12C0; Mon, 25 Jun 2001 17:52:36 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay1.corp.hp.com (Postfix) with ESMTP id ED7031F502; Mon, 25 Jun 2001 10:52:02 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 17:52:35 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0914C@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Black_David@emc.com'" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Mon, 25 Jun 2001 17:52:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > So, let me acknowledge Marj's position that use of SendTargets > to describe other systems should be allowed, and solicit > other comments on this issue. In particular, I'd like to > hear from those who want to make sure that SendTargets > will be able to be retired in the future. Well actually, my position is that SendTargets responses should be allowed to include everything that you know about your own implementation, which may include other TCP/IP addresses (aggregation tags included), and other target names that your implementation exports. If you allow this behavior, how do you preclude "targets reporting information about other targets"? How do you distinguish the two cases? Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com From owner-ips@ece.cmu.edu Mon Jun 25 22:51:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05149 for ; Mon, 25 Jun 2001 22:51:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5Q0j6211115 for ips-outgoing; Mon, 25 Jun 2001 20:45:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [128.221.10.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5Q0j5g11111 for ; Mon, 25 Jun 2001 20:45:05 -0400 (EDT) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 20:44:59 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E07094C@corpmx14.us.dg.com> From: Black_David@emc.com To: marjorie_krueger@hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Mon, 25 Jun 2001 20:41:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk I think Marj and I understand each other. The issue comes down to exactly this Q&A at the end of Marj's previous email: > > David > Marj > > Do you see a > > need for a SendTargets issued to system X to > > return information about system Y? > > No, but I see no reason to prohibit this. The potential reason to prohibit this is to limit the use of SendTargets to having a target system describe itself, which I thought was the sense of the discussion. If we don't limit SendTargets to that use, it will get used in the above fashion that has one target system describing others. In my opinion, this is a decision that we get to make exactly once - if we allow use of SendTargets to describe other systems, we will not be able to change that at a subsequent stage of the IETF standards process because use of it in that fashion will be established practice among multiple implementations. This may make transitioning away from SendTargets considerably more difficult. So, let me acknowledge Marj's position that use of SendTargets to describe other systems should be allowed, and solicit other comments on this issue. In particular, I'd like to hear from those who want to make sure that SendTargets will be able to be retired in the future. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jun 26 05:22:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25754 for ; Tue, 26 Jun 2001 05:22:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5Q7Jxf02665 for ips-outgoing; Tue, 26 Jun 2001 03:19:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from internaut.com ([64.38.134.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5Q7Jvg02658 for ; Tue, 26 Jun 2001 03:19:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id AAA21513; Tue, 26 Jun 2001 00:13:13 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 26 Jun 2001 00:13:13 -0700 (PDT) From: Bernard Aboba To: julian_satran@il.ibm.com cc: ips@ece.cmu.edu Subject: RE: profiles - a way to simplify iSCSI In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > However the draft addresses a wide spectrum of devices with different > requirements (as do most of the SCSI drafts). Some can be met only with > minimal requirement (most low-end and office raid-boxes) while others > require higher performance/reliability/maintainability etc. > > Profiles could clearly cluster the space and simplify implementation and > testing. > The differentiation you are looking for can be achieved without profiles. It is possible to have different requirements for initiators and targets. It is possible to define requirements for those initiators/targets that implement a certain feature. For example, IF you implement feature X, then you also need to do W, Y, and Z. Finally, one can always differentiate between "unconditionally compliant" (all MUST, MUST NOT, SHOULD, SHOULD NOTs), and "conditionally compliant" (all MUST and MUST NOTs but not all SHOULD or SHOULD NOTs) implementations. From owner-ips@ece.cmu.edu Tue Jun 26 15:52:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08541 for ; Tue, 26 Jun 2001 15:52:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5QHc0a20305 for ips-outgoing; Tue, 26 Jun 2001 13:38:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NEXUS.replicants.org.uk (pc-62-30-167-16-ca.blueyonder.co.uk [62.30.167.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5QHZRg20100 for ; Tue, 26 Jun 2001 13:35:30 -0400 (EDT) Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Tue, 26 Jun 2001 18:39:16 +0100 X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 13:29:49 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Tue, 26 Jun 2001 13:29:49 +0100 Received: from [132.151.1.177] (helo=loki.ietf.org) by imailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15EryV-0001GH-00; Tue, 26 Jun 2001 13:29:48 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA18666 for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 07:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18511 for ; Tue, 26 Jun 2001 07:01:07 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26990; Tue, 26 Jun 2001 07:01:06 -0400 (EDT) Message-Id: <200106261101.HAA26990@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-iscsi-mib-01.txt Date: Tue, 26 Jun 2001 07:01:05 -0400 X-OriginalArrivalTime: 26 Jun 2001 17:39:16.0773 (UTC) FILETIME=[EC1BAD50:01C0FE66] Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for iSCSI Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-mib-01.txt Pages : 49 Date : 25-Jun-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-01.txt 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-mib-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-mib-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: <20010625095401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Cont --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jun 26 16:40:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14674 for ; Tue, 26 Jun 2001 16:40:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5QIMxD23707 for ips-outgoing; Tue, 26 Jun 2001 14:22:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5QIMvg23703 for ; Tue, 26 Jun 2001 14:22:58 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 11:22:52 -0700 Message-ID: From: Joshua Tseng To: ips@ece.cmu.edu Subject: New iSNS revision -04 available Date: Tue, 26 Jun 2001 11:22:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, I have submitted version -04 of the iSNS specification to the IETF. Until it is officially posted on the IETF IPS WG site, it can also be retrieved here: http://www.nishansystems.com/ietf/draft-ietf-ips-iSNS-04.txt As of yesterday, new open source iSNS code, including both iSNS client and server code, was made available on the ece.cmu.edu web site: http://www.ece.cmu.edu/~ips/IPS_Projects/ips_projects.html This newest code conforms to revision -04 of the iSNS specification, and also repairs some minor bugs introduced with the last-minute removal of FCIP. Regards, Josh From owner-ips@ece.cmu.edu Tue Jun 26 18:21:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28905 for ; Tue, 26 Jun 2001 18:21:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5QKgbg03753 for ips-outgoing; Tue, 26 Jun 2001 16:42:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5QKgag03749 for ; Tue, 26 Jun 2001 16:42:36 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA12725; Tue, 26 Jun 2001 16:42:09 -0400 (EDT) Message-ID: <3B38F298.3617AAA7@cisco.com> Date: Tue, 26 Jun 2001 15:37:44 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Black_David@emc.com CC: marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: Re: iSCSI: Wrapping up SendTargets References: <277DD60FB639D511AC0400B0D068B71E07094C@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't see any reason to disallow what Marjorie is asking for. However, we should also decide whether or not a SendTargets response may contain a well-known/default/canonical target to which the initiator is expected to recursively issue a SendTargets command. Supporting that feature is much more likely to be a problem if we want implementations to transition to other discovery mechanisms in the future, as well as creating requirements to avoid loops. Any thoughts? -- Mark Black_David@emc.com wrote: > > I think Marj and I understand each other. The issue > comes down to exactly this Q&A at the end of > Marj's previous email: > > > > David > > Marj > > > > Do you see a > > > need for a SendTargets issued to system X to > > > return information about system Y? > > > > No, but I see no reason to prohibit this. > > The potential reason to prohibit this is to limit the > use of SendTargets to having a target system describe > itself, which I thought was the sense of the discussion. > If we don't limit SendTargets to that use, it will get > used in the above fashion that has one target system > describing others. > > In my opinion, this is a decision that we get to make > exactly once - if we allow use of SendTargets to describe > other systems, we will not be able to change that at a > subsequent stage of the IETF standards process because > use of it in that fashion will be established practice > among multiple implementations. This may make transitioning > away from SendTargets considerably more difficult. > > So, let me acknowledge Marj's position that use of SendTargets > to describe other systems should be allowed, and solicit > other comments on this issue. In particular, I'd like to > hear from those who want to make sure that SendTargets > will be able to be retired in the future. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jun 26 18:21:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28928 for ; Tue, 26 Jun 2001 18:21:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5QKYdt03166 for ips-outgoing; Tue, 26 Jun 2001 16:34:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5QKYbg03159 for ; Tue, 26 Jun 2001 16:34:37 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA19150 for ; Tue, 26 Jun 2001 16:34:31 -0400 (EDT) Message-ID: <3B38F0CE.B767C0C1@cisco.com> Date: Tue, 26 Jun 2001 15:30:06 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: SendTargets Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Assuming that we will be keeping SendTargets, it's time to clean it up, tie up loose ends, get its hair cut, shine its shoes, and generally attempt to make it presentable. Here are the outstanding issues: 1. Handling text responses larger than the PDU size. I'd like to start this in a separate thread. 2. Concisely specify SendTargets, and make it as clear and unabiguous as possible. I'll try to start this below. 3. Finish up the aggregation tag thread. 4. Decide what to call the default/well-known/canonical target to which SendTargets is issued. 5. Decide whether the SendTargets response should be limited in its scope. David and Marjorie already have a thread on this one. So anyway, here's an attempt at #2; stating the SendTargets requirements (partly from David's consensus call, and partly from the Naming & Discovery conference call): A device containing targets MUST support the SendTargets command. It MAY respond to a SendTargets request with its complete list of targets, or with a list of targets that is based on the initiator logged in to the session. An initiator MAY use the SendTargets command. The SendTargets Command is always sent within its own text message, after the connection is in its full feature phase. It MUST NOT combined with other commands or parameters. Only one SendTargets command may be sent within a given PDU. SendTargets Command Syntax: SendTargets=all Request all targets that the initiator is supposed to see. Valid only on the canonical session, not on an operational session. SendTargets=iscsi Request all address information for the iSCSI target to which this session is established. (same as ReportPortalGroups). Valid on an operational session only. SendTargets=iqn.com.cisco.blah.blah.blah Request all addresses for the given iSCSI target. Valid on the canonical session; valid on an operational session only if the target name is the same as the one to which the session is logged in. Only one target name may be specified in a given SendTargets= key. SendTargets Context When sent to the well-known target, the response MAY include other targets. When sent on an operational session to a real target, the response is as if that target was specified. The SendTargets Response The purpose of SendTargets is to discover "just enough" information for an initiator to be able to connect to a target. Returning things like public key certificates or miscellaneous information about the target is left for MIBs or other discovery mechanisms. Allowed fields are TargetName= and TargetAddress=. No other keys are returned. The definition of which targets and addresses to return given a SendTargets request is somewhat up to the target, subject to a few constraints: A SendTargets response MUST include targets accessible by the requesting initiator that are available through the to which the SendTargets command was issued. A SendTargets response MAY contain other targets. A SendTargets response SHOULD NOT contain targets to which the requesting initiator does not have access. Open issue: A SendTargets response MAY/MAYNOT??? contain other well-known targets. Iterators will be covered in a separate thread. I still need to write this up a bit better, but here it is for now. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jun 26 18:24:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29572 for ; Tue, 26 Jun 2001 18:24:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5QKI1d01914 for ips-outgoing; Tue, 26 Jun 2001 16:18:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe49.law11.hotmail.com [64.4.16.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5QKHxg01910 for ; Tue, 26 Jun 2001 16:18:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Jun 2001 13:17:53 -0700 X-Originating-IP: [66.31.72.75] From: "Eddy Quicksall" To: "Matt Wakeley" , References: <3B37B46B.702F762@agilent.com> Subject: Re: iSCSI: All text keys MUST be supported? Date: Tue, 26 Jun 2001 16:17:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 26 Jun 2001 20:17:53.0944 (UTC) FILETIME=[14C8B980:01C0FE7D] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1. When I read "MAY be selected by omission", I read that if one omits =none, then it means the same thing as =none. And that the other guy MUST adhere to that rule. What is your interpretation of the current text? 2. Why should we limit the length to 4095 bytes when 4096 is not a strange number? Especially when we have to round things to 4 byte multiples anyway (which means 4095+one wasted byte becomes 4096). It seems we just cheated ourselves out of 1 byte. Eddy ----- Original Message ----- From: "Matt Wakeley" To: Sent: Monday, June 25, 2001 6:00 PM Subject: Re: iSCSI: All text keys MUST be supported? > julian_satran@il.ibm.com wrote: > > > > 1.2.4 reads now: > > > > 1.1.1 Text Mode Negotiation > > > > During login and thereafter some session or connection parameters are > > negotiated through an exchange of textual information. > > > > In "list" negotiation, the offering party sends a list of values for a > > key in its order of preference. > > > > The responding party answers with the first value from the list it > > supports and is allowed to use for the specific initiator. > > > > The value "none" MUST always be used to indicate a missing function. > > However, none is a valid selection only if it is explicitly offered and > > MAY be selected by omission (i.e., =none MAY be omitted). > > Why MAY "=none" be selected by omission? This is just another one of > those "options" that we all hate. If it's none, explicitely say so. > > You also need to remove the "none MUST always be used to indicate a missing > function" because the following paragraph allows the use of "reject" or > "NotUnderstood" to indicate a missing function. > > These two paragraphs need cleaning up. > > > > > If a target is not supporting, or not allowed to use with a specific > > initiator, any of the offered options, it may use the value "reject". > > The values "none" and "reject" are reserved and must be used only as > > described here. Any key not understood is answered with > > "NotUnderstood". > > > > The general format of text negotiation is: > > > > Offer-> =,,..., > > Answer-> =|reject|NotUnderstood > > > > In "numerical" negotiations, the offering and responding party state a > > numerical value. The result of the negotiation is key dependent; > > frequently the lower or the higher of the two values is used. > > > > Although the initiator is the requesting party and controls the > > request-response initiation and termination the target can offer > > key=value pairs of its own as part of a sequence and not only in > > response to an identical key=value pair offered by the initiator. > > > > And 2.8.3 reads: > > > > 1.1.1 Text > > > > The initiator sends the target a set of key=value or key=list pairs > > encoded in UTF-8 Unicode. The key and value are separated by a '=' > > (0x3D) delimiter. Many key=value pairs can be included in the Text block > > by separating them with null (0x00) delimiters. A list is a set of > > values separated by comma (0x2C). Large binary items can be encoded > > using their hexadecimal representation (e.g., 8190 is 0x1FFE) or decimal > > representation. The maximum length of an individual value (not its > > string representation) is 255 bytes. > > > > The data length of a text command or response SHOULD be less than 4096 > > bytes. Key names MUST NOT exceed 64 bytes. Key values MUST NOT exceed > > 255 characters. > > data length should be less than PDUlength. > > -Matt > > > From owner-ips@ece.cmu.edu Tue Jun 26 19:47:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15345 for ; Tue, 26 Jun 2001 19:47:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5QMTRN11006 for ips-outgoing; Tue, 26 Jun 2001 18:29:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5QMTOg10990 for ; Tue, 26 Jun 2001 18:29:24 -0400 (EDT) Received: (cpmta 3965 invoked from network); 26 Jun 2001 15:29:18 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.206) with SMTP; 26 Jun 2001 15:29:18 -0700 X-Sent: 26 Jun 2001 22:29:18 GMT From: "Douglas Otis" To: "Mark Bakke" , Cc: , Subject: RE: iSCSI: Wrapping up SendTargets Date: Tue, 26 Jun 2001 15:27:11 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3B38F298.3617AAA7@cisco.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, Management within the transport is multiplexing functions that adds complexity. The selector has evolved into a discovery scheme that will introduce non-standard interfaces for sharing a common database and will introduce scaling problems related to primitive mechanisms afforded by key=value prompting. A default selector returning additional information could be limited to serving as feedback at the user interface. Something along the lines of an information page pertaining only to the current selection. Answering "who else" does not seem wise in general. Doug > I don't see any reason to disallow what Marjorie is asking > for. However, we should also decide whether or not a SendTargets > response may contain a well-known/default/canonical target to > which the initiator is expected to recursively issue a > SendTargets command. > > Supporting that feature is much more likely to be a problem > if we want implementations to transition to other discovery > mechanisms in the future, as well as creating requirements to > avoid loops. > > Any thoughts? > > -- > Mark > > Black_David@emc.com wrote: > > > > I think Marj and I understand each other. The issue > > comes down to exactly this Q&A at the end of > > Marj's previous email: > > > > > > David > > > Marj > > > > > > Do you see a > > > > need for a SendTargets issued to system X to > > > > return information about system Y? > > > > > > No, but I see no reason to prohibit this. > > > > The potential reason to prohibit this is to limit the > > use of SendTargets to having a target system describe > > itself, which I thought was the sense of the discussion. > > If we don't limit SendTargets to that use, it will get > > used in the above fashion that has one target system > > describing others. > > > > In my opinion, this is a decision that we get to make > > exactly once - if we allow use of SendTargets to describe > > other systems, we will not be able to change that at a > > subsequent stage of the IETF standards process because > > use of it in that fashion will be established practice > > among multiple implementations. This may make transitioning > > away from SendTargets considerably more difficult. > > > > So, let me acknowledge Marj's position that use of SendTargets > > to describe other systems should be allowed, and solicit > > other comments on this issue. In particular, I'd like to > > hear from those who want to make sure that SendTargets > > will be able to be retired in the future. > > > > Thanks, > > --David > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Tue Jun 26 19:53:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16482 for ; Tue, 26 Jun 2001 19:53:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5QM1Zm09327 for ips-outgoing; Tue, 26 Jun 2001 18:01:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5QM1Xg09321 for ; Tue, 26 Jun 2001 18:01:33 -0400 (EDT) Received: from sdsl-216-36-75-164.dsl.sjc.megapath.net (HELO somesh) (216.36.75.164) by smtp.mail.vip.sc5.yahoo.com with SMTP; 26 Jun 2001 22:01:31 -0000 X-Apparently-From: Reply-To: From: "Somesh Gupta" To: "Matt Wakeley" , Subject: RE: profiles - a way to simplify iSCSI Date: Tue, 26 Jun 2001 14:52:40 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3B33FB7C.99D99858@agilent.com> Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Been busy elsewhere a while. > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Matt Wakeley > Sent: Friday, June 22, 2001 7:14 PM > To: ips@ece.cmu.edu > Subject: Re: profiles - a way to simplify iSCSI > > > Somesh Gupta wrote: > > > > Mutliple > > > connections per session is there to take advantage of the 10GBE > > > link with the shortcomings of TCP, > > > > How? By skipping around the congestion control algorithms? What > > about the other flows in the network? > > Nobody said anything about skipping around congestion control. > TCP was not designed for the fast links that are available today, so > you'll probably need more than 1 connection to attain link rate. > Whether you have 1 or a thousand connections, congestion control > will still work (or else it's fundamentally broken anyway). Can you please specify what you mean by TCP not being designed for fast links (anything other than the congestion avoidance alogorithm) > > > > and markers are there to eliminate the cost of memory > > > subsystems required to buffer out of order TCP frames. > > > > Framing has other benefit but not having a fast memory > > system cannot be avoided (especially if the inrastructure > > is to be common.) Also markers and CRCs do not mix well > > together. > > How do they not mix well? > > > > Eliminate > > > these, and > > > you've you'll capitulate to Fibre Channel for anything but > slow storage > > > connects. > > > > I don't think so. The pull of a common infrastructure will > > be too strong. And in case you have not looked lately, > > memory is getting fast enough and cheap enough. The GigaHz > > PCs are driving this. > > Until memory becomes "free", iSCSI implementations will always > cost more than > FC implementations that do not require memory The question of economics is much wider in scope than whether you have additional $10 (or whatever) worth of memory. First you look at the solution cost, of which hardware probably forms less than a 1/3rd of the cost. Then you go down to specific components and below. Then you see the economies of scale etc. How many chips is your R&D cost spread across etc etc. So to focus on a specific amount of memory at a particular point in time is not the right way to look at it. > > -Matt _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ips@ece.cmu.edu Tue Jun 26 23:54:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03452 for ; Tue, 26 Jun 2001 23:54:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5R1nFM22411 for ips-outgoing; Tue, 26 Jun 2001 21:49:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tiny-teddy.aarnet.edu.au (IDENT:root@tiny-teddy.aarnet.edu.au [203.21.37.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5R1mpg22364 for ; Tue, 26 Jun 2001 21:48:52 -0400 (EDT) Received: from aarnet.edu.au (gt1.aarnet.adelaide.edu.au [129.127.180.236]) by tiny-teddy.aarnet.edu.au (8.11.0/8.11.0) with ESMTP id f5R1mPT05342; Wed, 27 Jun 2001 11:18:26 +0930 Message-ID: <3B393B4B.C7553620@aarnet.edu.au> Date: Wed, 27 Jun 2001 11:17:55 +0930 From: Glen Turner Organization: Australian Academic and Research Network X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-ac17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Bakke CC: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: Re: iSCSI: Wrapping up SendTargets References: <277DD60FB639D511AC0400B0D068B71E07094C@corpmx14.us.dg.com> <3B38F298.3617AAA7@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark Bakke wrote: > > I don't see any reason to disallow what Marjorie is asking > for... > Any thoughts? There's the question of seperation of control and data. My reading is that the spec to date assumes that these will be in the same host. Given the increasing complexity of the control services, I'm not sure that a disk CPU can economically meet the control requirements (I'm not a disk CPU expert). So the argument for SendTargets describing other targets it to allow a host that handles only control services (such as a daemon on a general-purpose CPU). Allowing a seperation also simplifies the firewalling task. I need to go and have a close read of the spec from this perspective so please regard the above as a very tentative remark, made very late in the day, whilst reaching for the asbestos underwear :-) Regards, Glen -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ From owner-ips@ece.cmu.edu Wed Jun 27 11:49:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15319 for ; Wed, 27 Jun 2001 11:49:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5RDEIp10800 for ips-outgoing; Wed, 27 Jun 2001 09:14:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from host2.onnethosting.com (host2.onnethosting.com [209.239.51.98]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5RDEGg10793 for ; Wed, 27 Jun 2001 09:14:16 -0400 (EDT) Received: from ntyoavf (sct-si.ser.netvision.net.il [212.143.110.17]) by host2.onnethosting.com (8.10.2/8.10.2) with SMTP id f5RCvJq17805; Wed, 27 Jun 2001 08:57:20 -0400 From: "Yoav" To: , Subject: Target selection in a multi-target TCP connection Date: Wed, 27 Jun 2001 15:59:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello David, I hope you will consider this question: If several targets use the same TCP connection (in a gateway application), how is the target selected in the Login process. Is it through Text command (maybe mapping the ISID to a target name)? Regards, Yoav Flint Systems Engineer SANcastle yoavf@sancastle.com From owner-ips@ece.cmu.edu Wed Jun 27 12:25:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09443 for ; Wed, 27 Jun 2001 12:25:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5RELr215717 for ips-outgoing; Wed, 27 Jun 2001 10:21:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5RDJZg11155 for ; Wed, 27 Jun 2001 09:19:35 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id PAA333796; Wed, 27 Jun 2001 15:19:26 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5RDJQt98386; Wed, 27 Jun 2001 15:19:26 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A78.0048FB83 ; Wed, 27 Jun 2001 15:17:09 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: Scott Bradner cc: ips@ece.cmu.edu Message-ID: Date: Wed, 27 Jun 2001 16:25:06 +0300 Subject: Re: profiles - a way to simplify iSCSI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Scott, I assumed (rightfully) that we are talking about "different profiles". What I had in mind was more of a "set of levels". Level 0 - only mandatory feature. Level 1 = Level 0 + all the optional A profile 0 device will talk to any device as if is a profile 0 (not using any optionals). A profile 1 can talk using profile 1 features only to a profile 1 but it can talk also to a profile 0 by avoiding all the optionals. The gain is in simplifying testing and predicting feature interaction (at the cost of flexibility). Regards, Julo Scott Bradner on 27-06-2001 13:51:44 Please respond to Scott Bradner To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: profiles - a way to simplify iSCSI > Could you shed some light about the reasons behind this. its very straight forward - if you have profiles then it may become common that one ips devide will not be able to interopoerate with anothe ips device because they implemented different profiles - see X.400 for a worked example Scott From owner-ips@ece.cmu.edu Wed Jun 27 12:25:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09504 for ; Wed, 27 Jun 2001 12:25:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5REM6Z15734 for ips-outgoing; Wed, 27 Jun 2001 10:22:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5RDNig11472 for ; Wed, 27 Jun 2001 09:23:44 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id PAA246882; Wed, 27 Jun 2001 15:23:02 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5RDN2t192988; Wed, 27 Jun 2001 15:23:02 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A78.00495125 ; Wed, 27 Jun 2001 15:20:49 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu cc: bassoon@YOGI.PDL.CMU.EDU Message-ID: Date: Wed, 27 Jun 2001 16:28:41 +0300 Subject: mailing list Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, I do not receive mail from the list (since mid last week). Please address mail that you think should reach me adding me explicitly until the issue is fixed. Regards, Julo From owner-ips@ece.cmu.edu Wed Jun 27 12:27:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10219 for ; Wed, 27 Jun 2001 12:27:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5RELGl15635 for ips-outgoing; Wed, 27 Jun 2001 10:21:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5RAfng02027 for ; Wed, 27 Jun 2001 06:41:49 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA291980; Wed, 27 Jun 2001 12:41:41 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5RAfZt75762; Wed, 27 Jun 2001 12:41:41 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A78.003A89BB ; Wed, 27 Jun 2001 12:39:23 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: Scott Bradner cc: ips@ece.cmu.edu Message-ID: Date: Wed, 27 Jun 2001 04:56:58 +0300 Subject: Re: profiles - a way to simplify iSCSI Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Scott, Could you shed some light about the reasons behind this. Are we talking about the same thing or are we just using a word with two different meanings? Julo ________________ [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: profiles - a way to simplify iSCSI SORT BY: To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI LIST From: Scott Bradner ORDER Date: Fri, 22 Jun 2001 19:13:25 -0400 (EDT) THREAD Sender: owner-ips@ece.cmu.edu AUTHOR SUBJECT SEARCH there seems to be a misunderstanding somewhere - I was trying to say nicely that a IPS protocol that has to have profiles would not pass the IESG but I guess I was too nice - IPS HOME I expect that teh IESG would return any such proposal to the WG for rework if such a proposal makes it to the IESG i.e the discussion in the followintg posting is not a productive path to be following Scott (one of the TSV area directors) ----- From owner-ips@ece.cmu.edu Fri Jun 22 17:05:13 2001 X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Date: Fri, 22 Jun 2001 15:59:06 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: profiles - a way to simplify iSCSI References: < 79CB6B56B942D411A9AB001083FCE91E10B509@san-exchange.dino > <3B33881A.D0568785@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Just noticed that we did not include descriptions for the columns in the spreadsheet. Here they are: 1st column - Section number of an internet-draft version of this spreadsheet, which we will generate if needed. 2nd column - Category; we divided up the different features into some categories that made sense to us. The first set is common to all iSCSI implementations; the second and third are for those features that apply just to targets or initiators. 3rd column - Feature; short description of each feature. 4th column - Reference; a reference to the section number of the iSCSI document that best describes the feature and its status. 5th column - Status. M = Mandatory O = Optional R = Recommended (we have none of these now) X = Prohibited (we have none of these, either) If numbers appear after the status, e.g. M:4.5, it means that the feature is mandatory if the feature numbered 4.5 is implemented. I just noticed that some of our numbers had changed, so a few of these might still be typos. 6th column - Value. This is used if the feature is more than just a check box; for instance, if an implementation supports "Data Digest - Other", it is used to indicate some reference to what "other" means. Hope this helps, Mark Mark Bakke wrote: > > We've been thinking about how to profile iSCSI implementations > as well, and Paul Congdon, Matthew Burbridge (both of HP) and > I have come up with a spreadsheet that sort of follows the PICS > pro-forma that the IEEE folks use. Anyway, it appears that this > might be a useful thing to start discussing. We have attempted > to list the major mandatory and optional features, but have not > had enough review time yet to guarantee that it exactly matches > the spec, so comments are welcome. > > Julian has placed it on his web page at: > > http://www.haifa.il.ibm.com/satran/ips/iSCSIv6_PICs-5.pd f > > I apologize that this is not in internet-draft form, or if this > list is not exactly the right place to do this. However, I think > that it will help show the sheer number of optional features we > are faced with, and may help us prioritize what must stay in the > protocol, and what we could live without in the interest of > simplicity. > > Hopefully, this will help. > > -- > Mark > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 Prev by Date: Re: profiles - a way to simplify iSCSI Next by Date: Re: profiles - a way to simplify iSCSI Prev by thread: Re: profiles - a way to simplify iSCSI Next by thread: Re: profiles - a way to simplify iSCSI Index(es): Date Thread Home Last updated: Sat Jun 23 14:16:50 2001 5155 messages in chronological order From owner-ips@ece.cmu.edu Wed Jun 27 12:29:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11237 for ; Wed, 27 Jun 2001 12:29:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5REKWx15574 for ips-outgoing; Wed, 27 Jun 2001 10:20:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5RAffg02011 for ; Wed, 27 Jun 2001 06:41:41 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA198518; Wed, 27 Jun 2001 12:41:32 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5RAfRt34194; Wed, 27 Jun 2001 12:41:31 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A78.003A876D ; Wed, 27 Jun 2001 12:39:17 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: bassoon@YOGI.PDL.CMU.EDU cc: ips@ece.cmu.edu Message-ID: Date: Wed, 27 Jun 2001 04:45:44 +0300 Subject: mailing list Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Dave, Do I still appear on the mailing list? For several days I did not receive mail from the list. Is this a general problem? I was just made aware about mails that I did not see by a colleague. Regards, Julo From owner-ips@ece.cmu.edu Wed Jun 27 15:51:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17998 for ; Wed, 27 Jun 2001 15:51:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5RHJ0W29765 for ips-outgoing; Wed, 27 Jun 2001 13:19:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5RHIwg29759 for ; Wed, 27 Jun 2001 13:18:58 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel1.hp.com (Postfix) with ESMTP id 9931C7F8 for ; Wed, 27 Jun 2001 13:18:57 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 259071F504 for ; Wed, 27 Jun 2001 13:18:03 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 13:18:57 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A09150@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" Subject: RE: iSCSI: Wrapping up SendTargets Date: Wed, 27 Jun 2001 13:18:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Sorry if this is a repost, I sent this message Monday and didn't see it posted: > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > Sent: Monday, June 25, 2001 5:53 PM > To: 'Black_David@emc.com'; KRUEGER,MARJORIE (HP-Roseville,ex1) > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Wrapping up SendTargets > > > > So, let me acknowledge Marj's position that use of SendTargets > > to describe other systems should be allowed, and solicit > > other comments on this issue. In particular, I'd like to > > hear from those who want to make sure that SendTargets > > will be able to be retired in the future. > > Well actually, my position is that SendTargets responses > should be allowed to include everything that you know about > your own implementation, which may include other TCP/IP > addresses (aggregation tags included), and other target names > that your implementation exports. > > If you allow this behavior, how do you preclude "targets > reporting information about other targets"? How do you > distinguish the two cases? > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > tel: +1 916 785 2656 > fax: +1 916 785 0391 > email: marjorie_krueger@hp.com > From owner-ips@ece.cmu.edu Wed Jun 27 15:54:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18041 for ; Wed, 27 Jun 2001 15:54:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5RIDR303827 for ips-outgoing; Wed, 27 Jun 2001 14:13:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5RI8qg03454 for ; Wed, 27 Jun 2001 14:08:52 -0400 (EDT) Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Jun 2001 10:33:03 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Jun 2001 10:32:43 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 27 Jun 2001 10:32:35 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 27 Jun 2001 10:32:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Timeout values for SCSI requests Date: Wed, 27 Jun 2001 10:32:05 -0700 Message-ID: <8CC03F47967BF14D9710887723FADDB6A581EC@win-msg-02.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Timeout values for SCSI requests Thread-Index: AcD/J+TQ4Qs0HqfdTJihVQAC6G6J6wABtjnA From: "Lakshmi Ramasubramanian" To: , X-OriginalArrivalTime: 27 Jun 2001 17:32:05.0520 (UTC) FILETIME=[15797100:01C0FF2F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f5RI8rg03455 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit iSCSI structures for SCSI commands do not have fields to indicate timeout values for various commands. Only CDBs can be sent across. Do we expect the target driver to determine the required timeout value based on the CDB Opcode? Or, is there a way for the initiator to explicitly indicate the timeout values? Thanks! -lakshmi From owner-ips@ece.cmu.edu Wed Jun 27 18:54:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15744 for ; Wed, 27 Jun 2001 18:54:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5RKWUG13970 for ips-outgoing; Wed, 27 Jun 2001 16:32:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5RKWSg13965 for ; Wed, 27 Jun 2001 16:32:28 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA45176 for ; Wed, 27 Jun 2001 15:27:01 -0500 Received: from f3n42e (d03nm042h.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f5RKVBv253426 for ; Wed, 27 Jun 2001 14:31:11 -0600 Importance: Normal Subject: RE: iSCSI: Wrapping up SendTargets To: ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 27 Jun 2001 13:31:08 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 06/27/2001 01:31:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, Marj asks: How do you distinguish the two cases (of reporting on stuff in the same box and stuff in other boxes)? I'd add: how do you test compliance? I think the standard should define the protocol, describe what it is intended to be used for (report about targets "in the same box"), and, if necessary, add SHOULD NOTs to discourage use as a more general environment-wide discovery mechanism. Jim Hafner "KRUEGER,MARJORIE (HP-Roseville,ex1)" @ece.cmu.edu on 06/27/2001 10:18:53 am Sent by: owner-ips@ece.cmu.edu To: "Ips Reflector (E-mail)" cc: Subject: RE: iSCSI: Wrapping up SendTargets Sorry if this is a repost, I sent this message Monday and didn't see it posted: > -----Original Message----- > From: KRUEGER,MARJORIE (HP-Roseville,ex1) > Sent: Monday, June 25, 2001 5:53 PM > To: 'Black_David@emc.com'; KRUEGER,MARJORIE (HP-Roseville,ex1) > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Wrapping up SendTargets > > > > So, let me acknowledge Marj's position that use of SendTargets > > to describe other systems should be allowed, and solicit > > other comments on this issue. In particular, I'd like to > > hear from those who want to make sure that SendTargets > > will be able to be retired in the future. > > Well actually, my position is that SendTargets responses > should be allowed to include everything that you know about > your own implementation, which may include other TCP/IP > addresses (aggregation tags included), and other target names > that your implementation exports. > > If you allow this behavior, how do you preclude "targets > reporting information about other targets"? How do you > distinguish the two cases? > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard > tel: +1 916 785 2656 > fax: +1 916 785 0391 > email: marjorie_krueger@hp.com > From owner-ips@ece.cmu.edu Wed Jun 27 23:21:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20846 for ; Wed, 27 Jun 2001 23:21:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5S0XDf28647 for ips-outgoing; Wed, 27 Jun 2001 20:33:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ariel.nishansystems.com (smtp.nishansystems.com [216.217.36.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5S0XCg28643 for ; Wed, 27 Jun 2001 20:33:12 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 17:33:05 -0700 Message-ID: From: Charles Monia To: ips@ece.cmu.edu Subject: RE: Timeout values for SCSI requests Date: Wed, 27 Jun 2001 17:33:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi: It's a lot simpler to have the host class driver set and enforce such timeouts (the class driver is that part of the host I/O stack responsible for device-specific I/O operations, such as REWIND). There's not much value in burdening the logical unit with the enforcement chore. Charles > -----Original Message----- > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] > Sent: Wednesday, June 27, 2001 10:32 AM > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > Subject: Timeout values for SCSI requests > > > iSCSI structures for SCSI commands do not have fields to indicate > timeout > values for various commands. Only CDBs can be sent across. Do > we expect > the target driver to determine the required timeout value based on the > CDB Opcode? Or, is there a way for the initiator to > explicitly indicate > the timeout values? > > Thanks! > -lakshmi > From owner-ips@ece.cmu.edu Thu Jun 28 02:12:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03861 for ; Thu, 28 Jun 2001 02:12:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5S4On512072 for ips-outgoing; Thu, 28 Jun 2001 00:24:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5S4Omg12068 for ; Thu, 28 Jun 2001 00:24:48 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 00:23:34 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070967@corpmx14.us.dg.com> From: Black_David@emc.com To: yoavf@sancastle.com, ips@ece.cmu.edu Subject: RE: Target selection in a multi-target TCP connection Date: Thu, 28 Jun 2001 00:21:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Huh? Login is to a single iSCSI target and binds the TCP connection to that target. The target name is specified in the login command (see description of TargetName text key), and the implementation has to track the connection binding as part of the state established by the login. If this isn't clearly specified in -06, please let us know what text needs to be clarified. Now, if one iSCSI target corresponds to multiple targets of some other sort (e.g., SCSI, FC) behind the gateway, dealing with this is the responsibility of the gateway implementer. One possibility is to create an iSCSI target per target behind the gateway, another might be to do some sort of clever LUN mapping. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Yoav [SMTP:yoavf@sancastle.com] > Sent: Wednesday, June 27, 2001 9:59 AM > To: Black_David@emc.com; ips@ece.cmu.edu > Subject: Target selection in a multi-target TCP connection > > Hello David, > > I hope you will consider this question: > If several targets use the same TCP connection (in a gateway > application), how is the target selected in > the Login process. Is it through Text command (maybe mapping the ISID > to a target name)? > > Regards, > Yoav Flint > Systems Engineer > SANcastle > yoavf@sancastle.com > From owner-ips@ece.cmu.edu Thu Jun 28 02:15:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04074 for ; Thu, 28 Jun 2001 02:15:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5S4GkN11646 for ips-outgoing; Thu, 28 Jun 2001 00:16:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [128.221.10.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5S4Gjg11642 for ; Thu, 28 Jun 2001 00:16:45 -0400 (EDT) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 00:16:40 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070966@corpmx14.us.dg.com> From: Black_David@emc.com To: mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Wrapping up SendTargets Date: Thu, 28 Jun 2001 00:13:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > I don't see any reason to disallow what Marjorie is asking > for. However, we should also decide whether or not a SendTargets > response may contain a well-known/default/canonical target to > which the initiator is expected to recursively issue a > SendTargets command. > > Supporting that feature is much more likely to be a problem > if we want implementations to transition to other discovery > mechanisms in the future, as well as creating requirements to > avoid loops. > > Any thoughts? On further thought, I agree. Forbidding recursive use of SendTargets prevents the nasty problem scenarios such as recursion problems/bugs that prevent discovery of things that should have been discovered and loops in the recursion structure. This prohibition is easy to specify - Initiators won't do the recursion, hence SendTargets MUST NOT return information about other canonical targets. IMHO, this is sufficient, and the tighter restriction based on same is not needed. If someone wants to have SendTargets return information about multiple systems, keeping that information correct and up to date across the systems is their problem, not ours (long version of "Marjorie was right"). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jun 28 02:15:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04100 for ; Thu, 28 Jun 2001 02:15:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5S4cJ312889 for ips-outgoing; Thu, 28 Jun 2001 00:38:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.6.9.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5S4cHg12885 for ; Thu, 28 Jun 2001 00:38:17 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id DBC0B1FA9 for ; Wed, 27 Jun 2001 22:38:10 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 96C10748 for ; Wed, 27 Jun 2001 22:38:10 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id VAA16125 for ; Wed, 27 Jun 2001 21:38:09 -0700 (PDT) Received: from agilent.com (cos1nai130104.cos.agilent.com [141.184.130.104]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA59CB for ; Wed, 27 Jun 2001 21:38:05 -0700 Message-ID: <3B3A0A5B.B2D2FEDE@agilent.com> Date: Wed, 27 Jun 2001 09:31:24 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: All text keys MUST be supported? References: <3B37B46B.702F762@agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy Quicksall wrote: > > 1. When I read "MAY be selected by omission", I read that if one omits > =none, then it means the same thing as =none. And that the other > guy MUST adhere to that rule. > > What is your interpretation of the current text? That's the problem - it can be interpreted many different ways. Just delete the "MAY be selected by omission". Make everything explicitely selected. Ok, so I should have said "less than or equal to PDUlength". My point is, that if PDUlength is less than 4096, the message length must not be larger than PDUlength. -Matt > > 2. Why should we limit the length to 4095 bytes when 4096 is not a strange > number? Especially when we have to round things to 4 byte multiples anyway > (which means 4095+one wasted byte becomes 4096). It seems we just cheated > ourselves out of 1 byte. > > Eddy > > ----- Original Message ----- > From: "Matt Wakeley" > To: > Sent: Monday, June 25, 2001 6:00 PM > Subject: Re: iSCSI: All text keys MUST be supported? > > > julian_satran@il.ibm.com wrote: > > > > > > 1.2.4 reads now: > > > > > > 1.1.1 Text Mode Negotiation > > > > > > During login and thereafter some session or connection parameters are > > > negotiated through an exchange of textual information. > > > > > > In "list" negotiation, the offering party sends a list of values for > a > > > key in its order of preference. > > > > > > The responding party answers with the first value from the list it > > > supports and is allowed to use for the specific initiator. > > > > > > The value "none" MUST always be used to indicate a missing function. > > > However, none is a valid selection only if it is explicitly offered > and > > > MAY be selected by omission (i.e., =none MAY be omitted). > > > > Why MAY "=none" be selected by omission? This is just another one of > > those "options" that we all hate. If it's none, explicitely say so. > > > > You also need to remove the "none MUST always be used to indicate a > missing > > function" because the following paragraph allows the use of "reject" or > > "NotUnderstood" to indicate a missing function. > > > > These two paragraphs need cleaning up. > > > > > > > > If a target is not supporting, or not allowed to use with a specific > > > initiator, any of the offered options, it may use the value "reject". > > > The values "none" and "reject" are reserved and must be used only as > > > described here. Any key not understood is answered with > > > "NotUnderstood". > > > > > > The general format of text negotiation is: > > > > > > Offer-> =,,..., > > > Answer-> =|reject|NotUnderstood > > > > > > In "numerical" negotiations, the offering and responding party state > a > > > numerical value. The result of the negotiation is key dependent; > > > frequently the lower or the higher of the two values is used. > > > > > > Although the initiator is the requesting party and controls the > > > request-response initiation and termination the target can offer > > > key=value pairs of its own as part of a sequence and not only in > > > response to an identical key=value pair offered by the initiator. > > > > > > And 2.8.3 reads: > > > > > > 1.1.1 Text > > > > > > The initiator sends the target a set of key=value or key=list pairs > > > encoded in UTF-8 Unicode. The key and value are separated by a '=' > > > (0x3D) delimiter. Many key=value pairs can be included in the Text > block > > > by separating them with null (0x00) delimiters. A list is a set of > > > values separated by comma (0x2C). Large binary items can be encoded > > > using their hexadecimal representation (e.g., 8190 is 0x1FFE) or > decimal > > > representation. The maximum length of an individual value (not its > > > string representation) is 255 bytes. > > > > > > The data length of a text command or response SHOULD be less than > 4096 > > > bytes. Key names MUST NOT exceed 64 bytes. Key values MUST NOT > exceed > > > 255 characters. > > > > data length should be less than PDUlength. > > > > -Matt > > > > > > From owner-ips@ece.cmu.edu Thu Jun 28 06:16:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10212 for ; Thu, 28 Jun 2001 06:16:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5S7sJA23675 for ips-outgoing; Thu, 28 Jun 2001 03:54:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from nest.stpt.soft.net ([203.200.144.37]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f5S7sGg23670 for ; Thu, 28 Jun 2001 03:54:17 -0400 (EDT) Received: from pdc2.nest.stpt.soft.net (pdc2 [192.168.192.5]) by nest.stpt.soft.net (8.6.8.1/SCA-6.6) with ESMTP id HAA04130 for ; Thu, 28 Jun 2001 07:07:02 GMT Organization: NeST India Received: by pdc2.nestec.net with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 13:22:25 +0530 Message-ID: From: FAIZAL C K To: ips@ece.cmu.edu Subject: How we find out a iSCSI device? Date: Thu, 28 Jun 2001 13:22:25 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Gurus... Can we find out a iSCSI device in the remote machine by Naming & discovery protocol? (Or by [:port>]/). If yes please explain that to me. Thanks in advance, Faizal From owner-ips@ece.cmu.edu Thu Jun 28 08:03:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12832 for ; Thu, 28 Jun 2001 08:03:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5S9vtr10784 for ips-outgoing; Thu, 28 Jun 2001 05:57:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from host2.onnethosting.com (host2.onnethosting.com [209.239.51.98]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5S9vsg10778 for ; Thu, 28 Jun 2001 05:57:54 -0400 (EDT) Received: from ntyoavf (sct-si.ser.netvision.net.il [212.143.110.17]) by host2.onnethosting.com (8.10.2/8.10.2) with SMTP id f5S9vnq21239; Thu, 28 Jun 2001 05:57:50 -0400 From: "Yoav" To: , Subject: RE: Target selection in a multi-target TCP connection Date: Thu, 28 Jun 2001 12:59:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the pointer and the reply. My interpration was wrong, however it could be better if some of the Login parameters which are a MUST (like TargetName text key?) would be mentioned under section 2.10.9 Yoav -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Black_David@emc.com Sent: Thu, June 28, 2001 6:22 AM To: yoavf@sancastle.com; ips@ece.cmu.edu Subject: RE: Target selection in a multi-target TCP connection Huh? Login is to a single iSCSI target and binds the TCP connection to that target. The target name is specified in the login command (see description of TargetName text key), and the implementation has to track the connection binding as part of the state established by the login. If this isn't clearly specified in -06, please let us know what text needs to be clarified. Now, if one iSCSI target corresponds to multiple targets of some other sort (e.g., SCSI, FC) behind the gateway, dealing with this is the responsibility of the gateway implementer. One possibility is to create an iSCSI target per target behind the gateway, another might be to do some sort of clever LUN mapping. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Yoav [SMTP:yoavf@sancastle.com] > Sent: Wednesday, June 27, 2001 9:59 AM > To: Black_David@emc.com; ips@ece.cmu.edu > Subject: Target selection in a multi-target TCP connection > > Hello David, > > I hope you will consider this question: > If several targets use the same TCP connection (in a gateway > application), how is the target selected in > the Login process. Is it through Text command (maybe mapping the ISID > to a target name)? > > Regards, > Yoav Flint > Systems Engineer > SANcastle > yoavf@sancastle.com > From owner-ips@ece.cmu.edu Thu Jun 28 12:50:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22366 for ; Thu, 28 Jun 2001 12:50:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5SEVSE27708 for ips-outgoing; Thu, 28 Jun 2001 10:31:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5SBEBg14785 for ; Thu, 28 Jun 2001 07:14:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10658; Thu, 28 Jun 2001 07:13:30 -0400 (EDT) Message-Id: <200106281113.HAA10658@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-isns-04.txt Date: Thu, 28 Jun 2001 07:13:29 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSNS Internet Storage Name Service Author(s) : K. Gibbons et al. Filename : draft-ietf-ips-isns-04.txt Pages : 74 Date : 27-Jun-01 This document provides a generic framework centering around use of the iSNS for discovery and management of iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale IP storage network. iSNS is an application that stores iSCSI and FC device attributes and monitors their availability and reachability in an integrated IP storage network. Due to its role as a consolidated information repository, iSNS provides for more efficient and scalable management of storage devices in an IP network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-isns-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-isns-04.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: <20010627132314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010627132314.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Jun 28 15:59:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04703 for ; Thu, 28 Jun 2001 15:59:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5SHi1V11959 for ips-outgoing; Thu, 28 Jun 2001 13:44:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe10.law11.hotmail.com [64.4.16.114]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5SHhwg11954 for ; Thu, 28 Jun 2001 13:43:58 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Jun 2001 10:43:52 -0700 X-Originating-IP: [66.31.72.75] From: "Eddy Quicksall" To: "Matt Wakeley" , References: <3B37B46B.702F762@agilent.com> <3B3A0A5B.B2D2FEDE@agilent.com> Subject: Re: iSCSI: All text keys MUST be supported? Date: Thu, 28 Jun 2001 13:43:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 28 Jun 2001 17:43:52.0563 (UTC) FILETIME=[E5516430:01C0FFF9] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1. Without something like "MAY be selected by omission", one would think it can't be omitted. Can you think of alternate text? 2. When I was "complaining" about the "less than 4096" below, I was not referring to what you said ... I was referring to what the spec says ("The data length of a text command or response SHOULD be less than 4096 bytes."). Does anyone know why we can't go to 4096 instead of 4095 as the spec currently says. Eddy ----- Original Message ----- From: "Matt Wakeley" To: Sent: Wednesday, June 27, 2001 12:31 PM Subject: Re: iSCSI: All text keys MUST be supported? > Eddy Quicksall wrote: > > > > 1. When I read "MAY be selected by omission", I read that if one omits > > =none, then it means the same thing as =none. And that the other > > guy MUST adhere to that rule. > > > > What is your interpretation of the current text? > > That's the problem - it can be interpreted many different ways. > Just delete the "MAY be selected by omission". Make everything explicitely > selected. > > Ok, so I should have said "less than or equal to PDUlength". > My point is, that if PDUlength is less than 4096, the message length must not > be larger than PDUlength. > > -Matt > > > > > 2. Why should we limit the length to 4095 bytes when 4096 is not a strange > > number? Especially when we have to round things to 4 byte multiples anyway > > (which means 4095+one wasted byte becomes 4096). It seems we just cheated > > ourselves out of 1 byte. > > > > Eddy > > > > ----- Original Message ----- > > From: "Matt Wakeley" > > To: > > Sent: Monday, June 25, 2001 6:00 PM > > Subject: Re: iSCSI: All text keys MUST be supported? > > > > > julian_satran@il.ibm.com wrote: > > > > > > > > 1.2.4 reads now: > > > > > > > > 1.1.1 Text Mode Negotiation > > > > > > > > During login and thereafter some session or connection parameters are > > > > negotiated through an exchange of textual information. > > > > > > > > In "list" negotiation, the offering party sends a list of values for > > a > > > > key in its order of preference. > > > > > > > > The responding party answers with the first value from the list it > > > > supports and is allowed to use for the specific initiator. > > > > > > > > The value "none" MUST always be used to indicate a missing function. > > > > However, none is a valid selection only if it is explicitly offered > > and > > > > MAY be selected by omission (i.e., =none MAY be omitted). > > > > > > Why MAY "=none" be selected by omission? This is just another one of > > > those "options" that we all hate. If it's none, explicitely say so. > > > > > > You also need to remove the "none MUST always be used to indicate a > > missing > > > function" because the following paragraph allows the use of "reject" or > > > "NotUnderstood" to indicate a missing function. > > > > > > These two paragraphs need cleaning up. > > > > > > > > > > > If a target is not supporting, or not allowed to use with a specific > > > > initiator, any of the offered options, it may use the value "reject". > > > > The values "none" and "reject" are reserved and must be used only as > > > > described here. Any key not understood is answered with > > > > "NotUnderstood". > > > > > > > > The general format of text negotiation is: > > > > > > > > Offer-> =,,..., > > > > Answer-> =|reject|NotUnderstood > > > > > > > > In "numerical" negotiations, the offering and responding party state > > a > > > > numerical value. The result of the negotiation is key dependent; > > > > frequently the lower or the higher of the two values is used. > > > > > > > > Although the initiator is the requesting party and controls the > > > > request-response initiation and termination the target can offer > > > > key=value pairs of its own as part of a sequence and not only in > > > > response to an identical key=value pair offered by the initiator. > > > > > > > > And 2.8.3 reads: > > > > > > > > 1.1.1 Text > > > > > > > > The initiator sends the target a set of key=value or key=list pairs > > > > encoded in UTF-8 Unicode. The key and value are separated by a '=' > > > > (0x3D) delimiter. Many key=value pairs can be included in the Text > > block > > > > by separating them with null (0x00) delimiters. A list is a set of > > > > values separated by comma (0x2C). Large binary items can be encoded > > > > using their hexadecimal representation (e.g., 8190 is 0x1FFE) or > > decimal > > > > representation. The maximum length of an individual value (not its > > > > string representation) is 255 bytes. > > > > > > > > The data length of a text command or response SHOULD be less than > > 4096 > > > > bytes. Key names MUST NOT exceed 64 bytes. Key values MUST NOT > > exceed > > > > 255 characters. > > > > > > data length should be less than PDUlength. > > > > > > -Matt > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jun 28 19:33:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19042 for ; Thu, 28 Jun 2001 19:33:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5SL1m526669 for ips-outgoing; Thu, 28 Jun 2001 17:01:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5SL1kg26665 for ; Thu, 28 Jun 2001 17:01:46 -0400 (EDT) Received: from london ([192.168.195.163]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id OAA26167; Thu, 28 Jun 2001 14:01:07 -0700 (PDT) From: "Rod Harrison" To: Cc: Subject: iSCSI: UNH plugfest Date: Thu, 28 Jun 2001 22:02:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit A couple of general questions regarding the upcoming iSCSI plugfest at UNH. What was the final decision on who is allowed to attend? Everyone or SNIA members only? Was there consensus on what op-codes to use after Julian's suggestion to use v07 codes with the v06 spec? Is there a collated version of the v06 errata? There have been quite a few changes as we move to v07, some of which were bug fixes in v06, I remember some header stuff specifically. It's probably a good idea to make sure everyone at the plugfest starts out on the same version of v06 if we can. Thanks, - Rod From owner-ips@ece.cmu.edu Thu Jun 28 19:34:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19576 for ; Thu, 28 Jun 2001 19:34:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5SKo4V25827 for ips-outgoing; Thu, 28 Jun 2001 16:50:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5SKo3g25823 for ; Thu, 28 Jun 2001 16:50:03 -0400 (EDT) Received: from london ([192.168.195.163]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id NAA18694 for ; Thu, 28 Jun 2001 13:49:25 -0700 (PDT) From: "Rod Harrison" To: Subject: RE: iSCSI: All text keys MUST be supported? Date: Thu, 28 Jun 2001 21:50:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We could make "none" required to be offered, alternatively remove the restriction that prevents =none if "none" isn't explicitly offered. - Rod > -----Original Message----- > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Eddy Quicksall > Sent: Thursday, June 28, 2001 6:44 PM > To: Matt Wakeley; ips@ece.cmu.edu > Subject: Re: iSCSI: All text keys MUST be supported? > > > 1. Without something like "MAY be selected by > omission", one would think it > can't be omitted. Can you think of alternate text? > 2. When I was "complaining" about the "less > than 4096" below, I was not > referring to what you said ... I was referring > to what the spec says ("The > data length of a text command or response > SHOULD be less than 4096 bytes."). > Does anyone know why we can't go to 4096 > instead of 4095 as the spec > currently says. > > Eddy > > ----- Original Message ----- > From: "Matt Wakeley" > To: > Sent: Wednesday, June 27, 2001 12:31 PM > Subject: Re: iSCSI: All text keys MUST be supported? > > > > Eddy Quicksall wrote: > > > > > > 1. When I read "MAY be selected by > omission", I read that if one omits > > > =none, then it means the same thing > as =none. And that the > other > > > guy MUST adhere to that rule. > > > > > > What is your interpretation of the current text? > > > > That's the problem - it can be interpreted > many different ways. > > Just delete the "MAY be selected by > omission". Make everything > explicitely > > selected. > > > > Ok, so I should have said "less than or > equal to PDUlength". > > My point is, that if PDUlength is less than > 4096, the message length must > not > > be larger than PDUlength. > > > > -Matt > > > > > > > > 2. Why should we limit the length to 4095 > bytes when 4096 is not a > strange > > > number? Especially when we have to round > things to 4 byte multiples > anyway > > > (which means 4095+one wasted byte becomes > 4096). It seems we just > cheated > > > ourselves out of 1 byte. > > > > > > Eddy > > > > > > ----- Original Message ----- > > > From: "Matt Wakeley" > > > To: > > > Sent: Monday, June 25, 2001 6:00 PM > > > Subject: Re: iSCSI: All text keys MUST be > supported? > > > > > > > julian_satran@il.ibm.com wrote: > > > > > > > > > > 1.2.4 reads now: > > > > > > > > > > 1.1.1 Text Mode Negotiation > > > > > > > > > > During login and thereafter some > session or connection parameters > are > > > > > negotiated through an exchange of > textual information. > > > > > > > > > > In "list" negotiation, the offering > party sends a list of values > for > > > a > > > > > key in its order of preference. > > > > > > > > > > The responding party answers with > the first value from the list > it > > > > > supports and is allowed to use for > the specific initiator. > > > > > > > > > > The value "none" MUST always be > used to indicate a missing > function. > > > > > However, none is a valid selection > only if it is explicitly > offered > > > and > > > > > MAY be selected by omission (i.e., > =none MAY be omitted). > > > > > > > > Why MAY "=none" be selected by > omission? This is just another > one of > > > > those "options" that we all hate. If > it's none, explicitely say so. > > > > > > > > You also need to remove the "none MUST > always be used to indicate a > > > missing > > > > function" because the following > paragraph allows the use of "reject" > or > > > > "NotUnderstood" to indicate a missing function. > > > > > > > > These two paragraphs need cleaning up. > > > > > > > > > > > > > > If a target is not supporting, or > not allowed to use with a > specific > > > > > initiator, any of the offered > options, it may use the value > "reject". > > > > > The values "none" and "reject" are > reserved and must be used only > as > > > > > described here. Any key not > understood is answered with > > > > > "NotUnderstood". > > > > > > > > > > The general format of text negotiation is: > > > > > > > > > > Offer-> > =,,..., > > > > > Answer-> > =|reject|NotUnderstood > > > > > > > > > > In "numerical" negotiations, the > offering and responding party > state > > > a > > > > > numerical value. The result of the > negotiation is key dependent; > > > > > frequently the lower or the higher > of the two values is used. > > > > > > > > > > Although the initiator is the > requesting party and controls the > > > > > request-response initiation and > termination the target can offer > > > > > key=value pairs of its own as part > of a sequence and not only in > > > > > response to an identical key=value > pair offered by the initiator. > > > > > > > > > > And 2.8.3 reads: > > > > > > > > > > 1.1.1 Text > > > > > > > > > > The initiator sends the target a > set of key=value or key=list > pairs > > > > > encoded in UTF-8 Unicode. The key > and value are separated by a > '=' > > > > > (0x3D) delimiter. Many key=value > pairs can be included in the > Text > > > block > > > > > by separating them with null (0x00) > delimiters. A list is a set > of > > > > > values separated by comma (0x2C). > Large binary items can be > encoded > > > > > using their hexadecimal > representation (e.g., 8190 is 0x1FFE) or > > > decimal > > > > > representation. The maximum length > of an individual value (not > its > > > > > string representation) is 255 bytes. > > > > > > > > > > The data length of a text command > or response SHOULD be less than > > > 4096 > > > > > bytes. Key names MUST NOT exceed > 64 bytes. Key values MUST NOT > > > exceed > > > > > 255 characters. > > > > > > > > data length should be less than PDUlength. > > > > > > > > -Matt > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Fri Jun 29 01:15:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18528 for ; Fri, 29 Jun 2001 01:15:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5T2uHq18396 for ips-outgoing; Thu, 28 Jun 2001 22:56:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5T2uFg18392 for ; Thu, 28 Jun 2001 22:56:15 -0400 (EDT) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5T2uDx27781; Thu, 28 Jun 2001 19:56:14 -0700 (PDT) Received: from DAPW2K (sjc-vpn-tmp196.cisco.com [10.21.64.196]) by sponge.cisco.com (Mirapoint) with SMTP id AAN00655; Thu, 28 Jun 2001 21:55:17 -0500 (CDT) From: "Dave Peterson" To: "Rod Harrison" Cc: , Subject: RE: iSCSI: UNH plugfest Date: Thu, 28 Jun 2001 21:56:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Some answers to your questions: Anyone who has paid the appropriate fees and has a valid implementation is allowed to attend this plugfest. Below are the opcodes applicable for Rev 06+ testing at the UNH Plugfest: Valid initiator opcodes are: 0x00 NOP-Out (from initiator to target) 0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block) 0x02 SCSI Task Management Command 0x03 Login Command 0x04 Text Command 0x05 SCSI Data-out (for WRITE operations) 0x06 Logout Command 0x10 SNACK Request Valid target opcodes are: 0x20 NOP-In (from target to initiator) 0x21 SCSI Response (contains SCSI status and possibly sense information or other response information) 0x22 SCSI Task Management Response 0x23 Login Response 0x24 Text Response 0x25 SCSI Data-in (for READ operations) 0x26 Logout Response 0x31 Ready To Transfer (R2T - sent by target to initiator when it is ready to receive data from initiator) 0x32 Asynchronous Message (sent by target to initiator to indicate certain special conditions) 0x3f Reject Initiator opcodes 0x1c-0x1e and target opcodes 0x3c-0x3e are vendor specific codes. Rev 0.0 interoperability testing will be performed against the July 10, 2000 version of iSCSI (draft-satran-iscsi-01.txt) along with the SendTargets command. Not aware of any collated rev 06 errata at this time. I'll see if we can up with something. Dave -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Rod Harrison Sent: Thursday, June 28, 2001 4:03 PM To: ips@ece.cmu.edu Cc: julian_satran@il.ibm.com Subject: iSCSI: UNH plugfest A couple of general questions regarding the upcoming iSCSI plugfest at UNH. What was the final decision on who is allowed to attend? Everyone or SNIA members only? Was there consensus on what op-codes to use after Julian's suggestion to use v07 codes with the v06 spec? Is there a collated version of the v06 errata? There have been quite a few changes as we move to v07, some of which were bug fixes in v06, I remember some header stuff specifically. It's probably a good idea to make sure everyone at the plugfest starts out on the same version of v06 if we can. Thanks, - Rod From owner-ips@ece.cmu.edu Fri Jun 29 13:35:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20265 for ; Fri, 29 Jun 2001 13:35:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TFlJ714795 for ips-outgoing; Fri, 29 Jun 2001 11:47:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TFlIg14790 for ; Fri, 29 Jun 2001 11:47:18 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA165260; Fri, 29 Jun 2001 17:47:10 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5TFl68116580; Fri, 29 Jun 2001 17:47:11 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A7A.005680C6 ; Fri, 29 Jun 2001 17:44:50 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: "Lakshmi Ramasubramanian" cc: ips@ece.cmu.edu Message-ID: Date: Fri, 29 Jun 2001 18:45:31 +0300 Subject: RE: Timeout values for SCSI requests Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Usually timeouts are set and enforced by the (class) driver at initiator. Julo "Lakshmi Ramasubramanian" on 28-06-2001 21:13:13 Please respond to "Lakshmi Ramasubramanian" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: Timeout values for SCSI requests Julian, I agree transport timeouts should be fixed based on round trip delays, etc. But I was refering to the timeout value to be set by the target driver when it sends the scsi command to the device - I mean, the timer starts ticking after the scsi layer on the target has sent the command to the device. As you know this'd depend on the device type, command, etc. Thanks! -lakshmi -----Original Message----- From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] Sent: Thursday, June 28, 2001 6:06 AM To: Lakshmi Ramasubramanian Subject: Re: Timeout values for SCSI requests Lakshmi, It was felt that execution timeouts are beyond the scope of iSCSI and transport timeouts should be determined dynamically based on the measured round trip delays. Julo "Lakshmi Ramasubramanian" on 27-06-2001 20:32:05 Please respond to "Lakshmi Ramasubramanian" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: Timeout values for SCSI requests iSCSI structures for SCSI commands do not have fields to indicate timeout values for various commands. Only CDBs can be sent across. Do we expect the target driver to determine the required timeout value based on the CDB Opcode? Or, is there a way for the initiator to explicitly indicate the timeout values? Thanks! -lakshmi From owner-ips@ece.cmu.edu Fri Jun 29 13:38:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20363 for ; Fri, 29 Jun 2001 13:38:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TGBPh16461 for ips-outgoing; Fri, 29 Jun 2001 12:11:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TGBNg16456 for ; Fri, 29 Jun 2001 12:11:23 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5TGBMA05028 for ; Fri, 29 Jun 2001 12:11:22 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5TG9I901356 for ; Fri, 29 Jun 2001 12:10:33 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: iSCSI: UNH plugfest MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 29 Jun 2001 12:09:17 -0400 Disposition-Notification-To: "Elizabeth Rodriguez" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D453823649836040819@nc8220exchange.ral.lucent.com> Thread-Topic: iSCSI: UNH plugfest Thread-Index: AcEAHvT8vlyY8z0SSe6+wbyHuBOi2QAlZx6g From: "Elizabeth Rodriguez" To: "Rod Harrison" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f5TGBNg16457 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, To confirm: This plugfest is opened to everyone, not just SNIA members, that sign up and pay the appropriate registration fees for the plugfest. Information on the plugfest can be found at http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html. In addition, a plugfest for FCIP is planned for the same week, same location. Information on the FCIP section should be forthcoming sometime later today. Thanks, Elizabeth Rodriguez -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Thursday, June 28, 2001 4:03 PM To: ips@ece.cmu.edu Cc: julian_satran@il.ibm.com Subject: iSCSI: UNH plugfest A couple of general questions regarding the upcoming iSCSI plugfest at UNH. What was the final decision on who is allowed to attend? Everyone or SNIA members only? Was there consensus on what op-codes to use after Julian's suggestion to use v07 codes with the v06 spec? Is there a collated version of the v06 errata? There have been quite a few changes as we move to v07, some of which were bug fixes in v06, I remember some header stuff specifically. It's probably a good idea to make sure everyone at the plugfest starts out on the same version of v06 if we can. Thanks, - Rod From owner-ips@ece.cmu.edu Fri Jun 29 13:43:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20507 for ; Fri, 29 Jun 2001 13:43:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TFlEn14786 for ips-outgoing; Fri, 29 Jun 2001 11:47:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TFlCg14780 for ; Fri, 29 Jun 2001 11:47:12 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA100038 for ; Fri, 29 Jun 2001 17:47:04 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f5TFl58116578 for ; Fri, 29 Jun 2001 17:47:05 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A7A.00568107 ; Fri, 29 Jun 2001 17:44:51 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Fri, 29 Jun 2001 18:51:01 +0300 Subject: Re: iSCSI: All text keys MUST be supported? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk The current text reads: The data length of a text command or response SHOULD not exceed 4096 bytes. Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed 255 characters. The reaseon for 63, 255 is to enable a separator in the 256 (64) count. Julo "Eddy Quicksall" on 28-06-2001 20:43:48 Please respond to "Eddy Quicksall" To: "Matt Wakeley" , ips@ece.cmu.edu cc: Subject: Re: iSCSI: All text keys MUST be supported? 1. Without something like "MAY be selected by omission", one would think it can't be omitted. Can you think of alternate text? 2. When I was "complaining" about the "less than 4096" below, I was not referring to what you said ... I was referring to what the spec says ("The data length of a text command or response SHOULD be less than 4096 bytes."). Does anyone know why we can't go to 4096 instead of 4095 as the spec currently says. Eddy ----- Original Message ----- From: "Matt Wakeley" To: Sent: Wednesday, June 27, 2001 12:31 PM Subject: Re: iSCSI: All text keys MUST be supported? > Eddy Quicksall wrote: > > > > 1. When I read "MAY be selected by omission", I read that if one omits > > =none, then it means the same thing as =none. And that the other > > guy MUST adhere to that rule. > > > > What is your interpretation of the current text? > > That's the problem - it can be interpreted many different ways. > Just delete the "MAY be selected by omission". Make everything explicitely > selected. > > Ok, so I should have said "less than or equal to PDUlength". > My point is, that if PDUlength is less than 4096, the message length must not > be larger than PDUlength. > > -Matt > > > > > 2. Why should we limit the length to 4095 bytes when 4096 is not a strange > > number? Especially when we have to round things to 4 byte multiples anyway > > (which means 4095+one wasted byte becomes 4096). It seems we just cheated > > ourselves out of 1 byte. > > > > Eddy > > > > ----- Original Message ----- > > From: "Matt Wakeley" > > To: > > Sent: Monday, June 25, 2001 6:00 PM > > Subject: Re: iSCSI: All text keys MUST be supported? > > > > > julian_satran@il.ibm.com wrote: > > > > > > > > 1.2.4 reads now: > > > > > > > > 1.1.1 Text Mode Negotiation > > > > > > > > During login and thereafter some session or connection parameters are > > > > negotiated through an exchange of textual information. > > > > > > > > In "list" negotiation, the offering party sends a list of values for > > a > > > > key in its order of preference. > > > > > > > > The responding party answers with the first value from the list it > > > > supports and is allowed to use for the specific initiator. > > > > > > > > The value "none" MUST always be used to indicate a missing function. > > > > However, none is a valid selection only if it is explicitly offered > > and > > > > MAY be selected by omission (i.e., =none MAY be omitted). > > > > > > Why MAY "=none" be selected by omission? This is just another one of > > > those "options" that we all hate. If it's none, explicitely say so. > > > > > > You also need to remove the "none MUST always be used to indicate a > > missing > > > function" because the following paragraph allows the use of "reject" or > > > "NotUnderstood" to indicate a missing function. > > > > > > These two paragraphs need cleaning up. > > > > > > > > > > > If a target is not supporting, or not allowed to use with a specific > > > > initiator, any of the offered options, it may use the value "reject". > > > > The values "none" and "reject" are reserved and must be used only as > > > > described here. Any key not understood is answered with > > > > "NotUnderstood". > > > > > > > > The general format of text negotiation is: > > > > > > > > Offer-> =,,..., > > > > Answer-> =|reject|NotUnderstood > > > > > > > > In "numerical" negotiations, the offering and responding party state > > a > > > > numerical value. The result of the negotiation is key dependent; > > > > frequently the lower or the higher of the two values is used. > > > > > > > > Although the initiator is the requesting party and controls the > > > > request-response initiation and termination the target can offer > > > > key=value pairs of its own as part of a sequence and not only in > > > > response to an identical key=value pair offered by the initiator. > > > > > > > > And 2.8.3 reads: > > > > > > > > 1.1.1 Text > > > > > > > > The initiator sends the target a set of key=value or key=list pairs > > > > encoded in UTF-8 Unicode. The key and value are separated by a '=' > > > > (0x3D) delimiter. Many key=value pairs can be included in the Text > > block > > > > by separating them with null (0x00) delimiters. A list is a set of > > > > values separated by comma (0x2C). Large binary items can be encoded > > > > using their hexadecimal representation (e.g., 8190 is 0x1FFE) or > > decimal > > > > representation. The maximum length of an individual value (not its > > > > string representation) is 255 bytes. > > > > > > > > The data length of a text command or response SHOULD be less than > > 4096 > > > > bytes. Key names MUST NOT exceed 64 bytes. Key values MUST NOT > > exceed > > > > 255 characters. > > > > > > data length should be less than PDUlength. > > > > > > -Matt > > > > > > > > > > > From owner-ips@ece.cmu.edu Fri Jun 29 13:45:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20588 for ; Fri, 29 Jun 2001 13:45:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TGYsC18148 for ips-outgoing; Fri, 29 Jun 2001 12:34:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TGYqg18136 for ; Fri, 29 Jun 2001 12:34:52 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA19948; Fri, 29 Jun 2001 12:34:41 -0400 (EDT) Message-ID: <3B3CAD10.5CC5815C@cisco.com> Date: Fri, 29 Jun 2001 11:30:08 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Black_David@emc.com CC: ips@ece.cmu.edu Subject: Re: iSCSI: Wrapping up SendTargets References: <277DD60FB639D511AC0400B0D068B71E070966@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David- Your comments wrap this up from my point of view. We'll add: A SendTargets response MUST NOT include other "canonical" targets. This prevents an initiator from using SendTargets recursively, and getting into loop problems. This will keep things clean enough, and we don't have to disallow implementations from doing what Marjorie had wanted, and that Glen had provided another decent argument for. I'll post a new SendTargets section RSN. -- Mark Black_David@emc.com wrote: > > > I don't see any reason to disallow what Marjorie is asking > > for. However, we should also decide whether or not a SendTargets > > response may contain a well-known/default/canonical target to > > which the initiator is expected to recursively issue a > > SendTargets command. > > > > Supporting that feature is much more likely to be a problem > > if we want implementations to transition to other discovery > > mechanisms in the future, as well as creating requirements to > > avoid loops. > > > > Any thoughts? > > On further thought, I agree. Forbidding recursive use > of SendTargets prevents the nasty problem scenarios such as > recursion problems/bugs that prevent discovery of things that > should have been discovered and loops in the recursion structure. > > This prohibition is easy to specify - Initiators won't do the recursion, > hence SendTargets MUST NOT return information about other > canonical targets. IMHO, this is sufficient, and the tighter > restriction based on same is not > needed. If someone wants to have SendTargets return > information about multiple systems, keeping that information > correct and up to date across the systems is their > problem, not ours (long version of "Marjorie was right"). > > Thanks, > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jun 29 13:45:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20602 for ; Fri, 29 Jun 2001 13:45:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TGVcQ17950 for ips-outgoing; Fri, 29 Jun 2001 12:31:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TGVbg17946 for ; Fri, 29 Jun 2001 12:31:37 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA16285; Fri, 29 Jun 2001 12:31:13 -0400 (EDT) Message-ID: <3B3CAC40.CC6405B5@cisco.com> Date: Fri, 29 Jun 2001 11:26:40 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Glen Turner CC: Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu Subject: Re: iSCSI: Wrapping up SendTargets References: <277DD60FB639D511AC0400B0D068B71E07094C@corpmx14.us.dg.com> <3B38F298.3617AAA7@cisco.com> <3B393B4B.C7553620@aarnet.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen- I think that this is at least partially the sort of thing Marjorie had in mind. I strongly agree, and given Jim's comments (in a later email; I've been away), there's no way for someone "outside" to really know whether an implementation is returning targets for one or more "boxes" anyway. -- Mark Glen Turner wrote: > > Mark Bakke wrote: > > > > I don't see any reason to disallow what Marjorie is asking > > for... > > Any thoughts? > > There's the question of seperation of control and data. > My reading is that the spec to date assumes that these > will be in the same host. > > Given the increasing complexity of the control services, > I'm not sure that a disk CPU can economically meet > the control requirements (I'm not a disk CPU expert). > > So the argument for SendTargets describing other > targets it to allow a host that handles only control > services (such as a daemon on a general-purpose CPU). > > Allowing a seperation also simplifies the firewalling > task. > > I need to go and have a close read of the spec from > this perspective so please regard the above as a > very tentative remark, made very late in the day, > whilst reaching for the asbestos underwear :-) > > Regards, > Glen > > -- > Glen Turner Network Engineer > (08) 8303 3936 Australian Academic and Research Network > glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jun 29 17:36:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25733 for ; Fri, 29 Jun 2001 17:36:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TJRFF00398 for ips-outgoing; Fri, 29 Jun 2001 15:27:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TJRDg00392 for ; Fri, 29 Jun 2001 15:27:13 -0400 (EDT) Received: from colosus2.cup.hp.com (colosus2.cup.hp.com [15.13.128.145]) by palrel1.hp.com (Postfix) with ESMTP id 76D9E16FF; Fri, 29 Jun 2001 12:26:39 -0700 (PDT) Received: from gg736541.cup.hp.com (IDENT:root@gg736541.cup.hp.com [15.13.128.152]) by colosus2.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id MAA16401; Fri, 29 Jun 2001 12:26:37 -0700 (PDT) Received: from hp.com (IDENT:gwendalg@localhost [127.0.0.1]) by gg736541.cup.hp.com (8.9.3/8.8.7) with ESMTP id MAA28083; Fri, 29 Jun 2001 12:27:42 -0700 Message-ID: <3B3CD6AE.CA9ED970@hp.com> Date: Fri, 29 Jun 2001 12:27:42 -0700 From: Gwendal Grignou Organization: Hewlett Packard X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dave Peterson Cc: ips@ece.cmu.edu Subject: Re: iSCSI: UNH plugfest References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave Peterson wrote: > Below are the opcodes applicable for Rev 06+ testing at the UNH Plugfest: Those opcodes are different from Rev6 and I didn't find any document defining precisely Rev6+, just a bunch of mails. Not having a precise Rev6+ iSCSI draft will not ease interoperabilty. Why not stick to Rev6 draft published 04/19/2001 ? Regards, Gwendal. > Valid initiator opcodes are: > 0x00 NOP-Out (from initiator to target) > 0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block) > 0x02 SCSI Task Management Command > 0x03 Login Command > 0x04 Text Command > 0x05 SCSI Data-out (for WRITE operations) > 0x06 Logout Command > 0x10 SNACK Request > > Valid target opcodes are: > > 0x20 NOP-In (from target to initiator) > 0x21 SCSI Response (contains SCSI status and possibly sense > information or other response information) > 0x22 SCSI Task Management Response > 0x23 Login Response > 0x24 Text Response > 0x25 SCSI Data-in (for READ operations) > 0x26 Logout Response > 0x31 Ready To Transfer (R2T - sent by target to initiator when it > is ready to receive data from initiator) > 0x32 Asynchronous Message (sent by target to initiator to indicate > certain special conditions) > 0x3f Reject > > Initiator opcodes 0x1c-0x1e and target opcodes 0x3c-0x3e are vendor specific > codes. From owner-ips@ece.cmu.edu Fri Jun 29 17:38:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25774 for ; Fri, 29 Jun 2001 17:38:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TJv6e02309 for ips-outgoing; Fri, 29 Jun 2001 15:57:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TJv4g02305 for ; Fri, 29 Jun 2001 15:57:04 -0400 (EDT) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5TJuwh26769; Fri, 29 Jun 2001 12:56:58 -0700 (PDT) Received: from DAPW2K (sjc-vpn-370.cisco.com [10.21.65.114]) by sponge.cisco.com (Mirapoint) with SMTP id AAO03498; Fri, 29 Jun 2001 14:56:09 -0500 (CDT) From: "Dave Peterson" To: "Gwendal Grignou" Cc: Subject: RE: iSCSI: UNH plugfest Date: Fri, 29 Jun 2001 14:57:40 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3B3CD6AE.CA9ED970@hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit As previously announced by UNH they will be using the opcodes below. Thus it would be a good idea for us to also use them. Dave -----Original Message----- From: gwendalg@gg736541.cup.hp.com [mailto:gwendalg@gg736541.cup.hp.com]On Behalf Of Gwendal Grignou Sent: Friday, June 29, 2001 2:28 PM To: Dave Peterson Cc: ips@ece.cmu.edu Subject: Re: iSCSI: UNH plugfest Dave Peterson wrote: > Below are the opcodes applicable for Rev 06+ testing at the UNH Plugfest: Those opcodes are different from Rev6 and I didn't find any document defining precisely Rev6+, just a bunch of mails. Not having a precise Rev6+ iSCSI draft will not ease interoperabilty. Why not stick to Rev6 draft published 04/19/2001 ? Regards, Gwendal. > Valid initiator opcodes are: > 0x00 NOP-Out (from initiator to target) > 0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block) > 0x02 SCSI Task Management Command > 0x03 Login Command > 0x04 Text Command > 0x05 SCSI Data-out (for WRITE operations) > 0x06 Logout Command > 0x10 SNACK Request > > Valid target opcodes are: > > 0x20 NOP-In (from target to initiator) > 0x21 SCSI Response (contains SCSI status and possibly sense > information or other response information) > 0x22 SCSI Task Management Response > 0x23 Login Response > 0x24 Text Response > 0x25 SCSI Data-in (for READ operations) > 0x26 Logout Response > 0x31 Ready To Transfer (R2T - sent by target to initiator when it > is ready to receive data from initiator) > 0x32 Asynchronous Message (sent by target to initiator to indicate > certain special conditions) > 0x3f Reject > > Initiator opcodes 0x1c-0x1e and target opcodes 0x3c-0x3e are vendor specific > codes. From owner-ips@ece.cmu.edu Fri Jun 29 19:09:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26934 for ; Fri, 29 Jun 2001 19:09:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TLh0808858 for ips-outgoing; Fri, 29 Jun 2001 17:43:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TLgwg08853 for ; Fri, 29 Jun 2001 17:42:58 -0400 (EDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5TLgvN21837 for ; Fri, 29 Jun 2001 17:42:57 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5TLguf21831 for ; Fri, 29 Jun 2001 17:42:56 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: UNH FCIP Plugfest MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C100E4.7545A214" Date: Fri, 29 Jun 2001 17:42:56 -0400 Disposition-Notification-To: "Elizabeth Rodriguez" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D45382364983604356E@nc8220exchange.ral.lucent.com> Thread-Topic: UNH FCIP Plugfest Thread-Index: AcEA3nN0oFTXFKfbRK6CuumuaJaOQwABe9Yg From: "Elizabeth Rodriguez" To: "Glen Shok" , Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C100E4.7545A214 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 This plugfest is open to all companies who wish to participate, provided they pay the associated plugfest fees. While sponsored by SNIA, a company does not need to be a member of the SNIA organization to participate. =20 More information about the plugfest can be found via the URL below. =20 Thanks, =20 Elizabeth -----Original Message----- From: Glen Shok [mailto:glen.shok@sanvalley.com] Sent: Friday, June 29, 2001 3:55 PM To: snia-ips@snia.org; ips@ece.cmu.edu Subject: UNH FCIP Plugfest Attached is the proposed test plan for the FCIP portion of the UNH Plugfest to be held the week of July 16, 2001. The goal is to test interoperability of FCIP equipment with available Fibre Channel Switches and IP Switches/Routers. There will also be analyzers available to simulate packet loss, congestion and traffic. We are still looking for participants for this event, please register below. =20 Also, please send me an e-mail if you plan to attend, or are a FC/GigE vendor and wish to pony up some gear. Information on the plugfest can be found at http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html. If you have any questions, please feel free to e-mail me glen.shok@sanvalley.com =20 Thank you, Glen Shok Product Manager SAN Valley Systems glen.shok@sanvalley.com Desk: 1.408.626.1220 Cell : 1.650.814.5921=20 ------_=_NextPart_001_01C100E4.7545A214 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
This=20 plugfest is open to all companies who wish to participate, provided they = pay the=20 associated plugfest fees.
While=20 sponsored by SNIA, a company does not need to be a member of the SNIA=20 organization to participate.
 
More=20 information about the plugfest can be found via the URL=20 below.
 
Thanks,
 
Elizabeth
-----Original Message-----
From: Glen Shok=20 [mailto:glen.shok@sanvalley.com]
Sent: Friday, June 29, 2001 = 3:55=20 PM
To: snia-ips@snia.org; ips@ece.cmu.edu
Subject: = UNH=20 FCIP Plugfest

Attached is the proposed test = plan for the=20 FCIP portion of the UNH Plugfest to be held the week of July 16, = 2001.
The=20 goal is to test interoperability of FCIP equipment with available = Fibre=20 Channel Switches and IP Switches/Routers.

There will also be analyzers = available to=20 simulate packet loss, congestion and traffic.

We are still looking for = participants for=20 this event, please register below. 

Also, please send me an e-mail if = you plan to=20 attend, or are a FC/GigE vendor and wish to pony up some=20 gear.

Information on the plugfest can be found at
http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html.

If you have any questions, = please feel free=20 to e-mail me glen.shok@sanvalley.com
 

Thank you,


Glen Shok
Product Manager
SAN Valley=20 Systems
glen.shok@sanvalley.com
Desk: = 1.408.626.1220
Cell  :=20 1.650.814.5921

------_=_NextPart_001_01C100E4.7545A214-- From owner-ips@ece.cmu.edu Fri Jun 29 19:17:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27036 for ; Fri, 29 Jun 2001 19:17:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TKN1203944 for ips-outgoing; Fri, 29 Jun 2001 16:23:01 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TKMxg03939 for ; Fri, 29 Jun 2001 16:22:59 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA09726 for ; Fri, 29 Jun 2001 16:22:53 -0400 (EDT) Message-ID: <3B3CE28C.F9748D5C@cisco.com> Date: Fri, 29 Jun 2001 15:18:20 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: iSCSI: Iterating long text responses Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Initiator developers- Please respond to the questions at the end. Thanks, Mark The current iSCSI draft allows text command and response PDUs of up to 4096 bytes. While we don't see any real problems for the command PDU size, commands such as SendTargets can easily exceed the response size. There are several ways we can fix this. The first two solutions require no differences in the current iSCSI text command and response; the latter three involve the use of the F bit. 1. Assume that such commands are done on a "special" connection or are handled completely in software, and allow its response PDU to be as large as it needs to be. This one appears too restrictive to be a solid solution. It will also weaken any data digests done on the longer PDU. 2. Create an iterative SendTargets key (and do the same for any other text commands that need this), that would allow the initiator to request the "next target" or "next address". This would work, but would require any new command that needed a large response to implement an iterator. It also means that each part of the response from the iterator would have to fit in the 4k PDU. The remainder of these require that only one text command sequence be outstanding on a connection at a given time. They use the F bit to indicate the last PDU of the sequence. Note that connection allegiance is assumed for the entire sequence, and text commands are never retried on another connection; a new command is issued instead. 3. Do a text-response R2T, where the initiator controls when the next partial response is sent. This would be more generic: I->T Text Command (F bit set) T->I Text Response (first PDU, F bit cleared) I->T Text Command (with some indicator that we want more) T->I Text Response (next PDU, F bit cleared) ... I->T Text Command (with indicator that we want more) T->I Text Response (last PDU, F bit set) The main problem with this is that the target must keep track of the state of its responses; if the initiator just stops asking, it may have to keep a buffered response around until it times out, the connection is dropped, or another text command comes along. 4. Allow multiple response PDUs to a single text command: I->T Text Command (F bit set) T->I Text Response (first PDU, F bit cleared) T->I Text Response (next PDU, F bit cleared) ... T->I Text Response (last PDU, F bit set) Basically, we are doing (3) without the R2T. The initiator, upon sending the text command, must be prepared either to accept as many PDUs as come back, or throw them away if it can't handle them. This solution is a lot like #1, but with the response spread across 4k PDUs. Also note that this (and the following scheme) avoid the problem of the target keeping state; it sends ALL of the response PDUs without the initiator asking for them. 5. Do #4, but allow the initiator to specify the amount of data it is willing to accept: I->T Text Command (F bit set, AcceptResponseLength=4096) T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) In the above example, we have created a new text command field: AcceptResponseLength And in the text response PDU: TotalResponseLength The initiator indicated it was willing to accept a 4k response. The target returned the first 4k in the text response, but set the F bit since it was at its limit. It also returned a TotalResponseLength field. Since this was greater than the AcceptResponseLength, the initiator knows the amount of buffer space it will need to get the full response. It can then choose whether it will re-send the command, and if so, can give it a large enough response length: I->T Text Command (F bit set, AcceptResponseLength=12288) T->I Text Response (first PDU, F bit clear) T->I Text Response (next PDU, F bit clear) T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) Note that most initiators will probably send an AcceptResponseLength of the largest response they would normally accept, and that most target responses will fit in one or a few PDUs anyway. #5 is really a compromise between #3 and #4; the target has the benefit of being less statefull, and the initiator has the benefit of controlling the amount of data it receives. I would like to recommend either #4 or #5. I think that #5 is probably the safest solution, but #4 may not be a problem for anyone. Assuming that none of the implementors of initiators have a problem with #4, I would pick that. If they do have a problem with it, we should go with #5. Targets probably don't care much whether we do #4 or #5. Initiator developers- Please indicate which solution (#4 or #5) appeals to you. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jun 29 20:10:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27920 for ; Fri, 29 Jun 2001 20:10:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TKxoo06255 for ips-outgoing; Fri, 29 Jun 2001 16:59:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from webmail.sanvalley.com (user.youreon.net [63.170.126.66] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TKxlg06250 for ; Fri, 29 Jun 2001 16:59:47 -0400 (EDT) Received: by webmail.sanvalley.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Jun 2001 13:54:48 -0700 Message-ID: <73DE11092C445F478CB3629910B2F49461A1A5@webmail.sanvalley.com> From: Glen Shok To: snia-ips@snia.org, ips@ece.cmu.edu Subject: UNH FCIP Plugfest Date: Fri, 29 Jun 2001 13:54:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C100DD.BBB8D6F0" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C100DD.BBB8D6F0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C100DD.BBB8D6F0" ------_=_NextPart_001_01C100DD.BBB8D6F0 Content-Type: text/plain; charset="iso-8859-1" Attached is the proposed test plan for the FCIP portion of the UNH Plugfest to be held the week of July 16, 2001. The goal is to test interoperability of FCIP equipment with available Fibre Channel Switches and IP Switches/Routers. There will also be analyzers available to simulate packet loss, congestion and traffic. We are still looking for participants for this event, please register below. Also, please send me an e-mail if you plan to attend, or are a FC/GigE vendor and wish to pony up some gear. Information on the plugfest can be found at http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html. If you have any questions, please feel free to e-mail me glen.shok@sanvalley.com Thank you, Glen Shok Product Manager SAN Valley Systems glen.shok@sanvalley.com Desk: 1.408.626.1220 Cell : 1.650.814.5921 ------_=_NextPart_001_01C100DD.BBB8D6F0 Content-Type: text/html; charset="iso-8859-1"

Attached is the proposed test plan for the FCIP portion of the UNH Plugfest to be held the week of July 16, 2001.
The goal is to test interoperability of FCIP equipment with available Fibre Channel Switches and IP Switches/Routers.

There will also be analyzers available to simulate packet loss, congestion and traffic.

We are still looking for participants for this event, please register below. 

Also, please send me an e-mail if you plan to attend, or are a FC/GigE vendor and wish to pony up some gear.

Information on the plugfest can be found at
http://www.iol.unh.edu/consortiums/iscsi/jul01gtp.html.

If you have any questions, please feel free to e-mail me glen.shok@sanvalley.com
 

Thank you,


Glen Shok
Product Manager
SAN Valley Systems
glen.shok@sanvalley.com
Desk: 1.408.626.1220
Cell  : 1.650.814.5921

------_=_NextPart_001_01C100DD.BBB8D6F0-- ------_=_NextPart_000_01C100DD.BBB8D6F0 Content-Type: application/octet-stream; name="FCIP-Interop-Test.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="FCIP-Interop-Test.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjE5IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAyMSANL0ggWyA3 MDIgMjE2IF0gDS9MIDczMDAxIA0vRSAzODE4IA0vTiA1IA0vVCA3MjUwMyANPj4gDWVuZG9iag0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTE5IDE1IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA2NDcgMDAwMDAgbg0KMDAw MDAwMDkxOCAwMDAwMCBuDQowMDAwMDAxMDcyIDAwMDAwIG4NCjAwMDAwMDEyMzEgMDAwMDAgbg0K MDAwMDAwMTQxMiAwMDAwMCBuDQowMDAwMDAxNTk0IDAwMDAwIG4NCjAwMDAwMDE3ODQgMDAwMDAg bg0KMDAwMDAwMjI2NCAwMDAwMCBuDQowMDAwMDAyNzcyIDAwMDAwIG4NCjAwMDAwMDI5NTIgMDAw MDAgbg0KMDAwMDAwMzE0MCAwMDAwMCBuDQowMDAwMDAzNTg5IDAwMDAwIG4NCjAwMDAwMDA3MDIg MDAwMDAgbg0KMDAwMDAwMDg5NyAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDM0DS9JbmZvIDE4 IDAgUiANL1Jvb3QgMjAgMCBSIA0vUHJldiA3MjQ5MyANL0lEWzxlNjhjOThiYWZhMzM3Mjk1MjA0 MjVlZjA4ZDRhOTVmZj48ZTY4Yzk4YmFmYTMzNzI5NTIwNDI1ZWYwOGQ0YTk1ZmY+XQ0+Pg1zdGFy dHhyZWYNMA0lJUVPRg0gICAgIA0yMCAwIG9iag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAx NyAwIFIgDT4+IA1lbmRvYmoNMzIgMCBvYmoNPDwgL1MgMTA0IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMzMgMCBSID4+IA1zdHJlYW0NCkiJYmBgYGZgYNrHwMLAwLWXgZ8BAfiBYiDI0QDm mrlni/JYPejqAHPVImre7mpVq74Fwluva2QBxTgYoAQUM1sgtAFZvAyMIhOANDfYbBDwY+BUE/F5 1tzmHZNmHnNAdLbjkTcMDAABBgBOmhnMDWVuZHN0cmVhbQ1lbmRvYmoNMzMgMCBvYmoNMTEwIA1l bmRvYmoNMjEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE3IDAgUiANL1Jlc291cmNl cyAyMiAwIFIgDS9Db250ZW50cyAzMCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9D cm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTIyIDAgb2JqDTw8 IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyNCAwIFIgL1RUNCAyNiAw IFIgL1RUNiAyNyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAzMSAwIFIgPj4gDS9Db2xvclNw YWNlIDw8IC9DczUgMjggMCBSID4+IA0+PiANZW5kb2JqDTIzIDAgb2JqDTw8IA0vVHlwZSAvRm9u dERlc2NyaXB0b3IgDS9Bc2NlbnQgOTA1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9G bGFncyAzMiANL0ZvbnRCQm94IFsgLTY2NSAtMzI1IDIwMjggMTAzNyBdIA0vRm9udE5hbWUgL0Fy aWFsTVQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMCANPj4gDWVuZG9iag0yNCAwIG9iag08PCAN L1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFy IDMyIA0vV2lkdGhzIFsgMjc4IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZv bnQgL0FyaWFsLUl0YWxpY01UIA0vRm9udERlc2NyaXB0b3IgMjUgMCBSIA0+PiANZW5kb2JqDTI1 IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgOTA1IA0vQ2FwSGVpZ2h0 IDAgDS9EZXNjZW50IC0yMTEgDS9GbGFncyA5NiANL0ZvbnRCQm94IFsgLTUxNyAtMzI1IDEwODIg MTAyNSBdIA0vRm9udE5hbWUgL0FyaWFsLUl0YWxpY01UIA0vSXRhbGljQW5nbGUgLTE1IA0vU3Rl bVYgMCANPj4gDWVuZG9iag0yNiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVl VHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDEyMiANL1dpZHRocyBbIDI3OCAwIDAgMCAw IDAgMCAwIDMzMyAzMzMgMCAwIDI3OCAzMzMgMjc4IDI3OCA1NTYgNTU2IDU1NiA1NTYgNTU2IA0w IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3 OCA1MDAgDTAgNTU2IDgzMyA3MjIgNzc4IDY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQg MCA2NjcgMCAwIDAgMCANMCAwIDAgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIg MjIyIDUwMCAyMjIgODMzIDU1NiA1NTYgDTU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIg NTAwIDUwMCA1MDAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvQXJp YWxNVCANL0ZvbnREZXNjcmlwdG9yIDIzIDAgUiANPj4gDWVuZG9iag0yNyAwIG9iag08PCANL1R5 cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDE0 NiANL1dpZHRocyBbIDI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjc4IDMzMyAyNzggMCA1NTYg NTU2IDU1NiA1NTYgNTU2IDAgNTU2IA0wIDAgNTU2IDMzMyAwIDAgMCAwIDAgMCA3MjIgNzIyIDcy MiAwIDAgNjExIDAgNzIyIDI3OCA1NTYgMCAwIDAgDTcyMiA3NzggNjY3IDAgMCA2NjcgNjExIDcy MiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDYxMSA1NTYgNjExIA01NTYgMzMzIDYxMSA2MTEg Mjc4IDI3OCAwIDI3OCA4ODkgNjExIDYxMSA2MTEgMCAzODkgNTU2IDMzMyA2MTEgDTU1NiA3Nzgg MCA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjc4 IA1dIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9BcmlhbC1Cb2xkTVQg DS9Gb250RGVzY3JpcHRvciAyOSAwIFIgDT4+IA1lbmRvYmoNMjggMCBvYmoNWyANL0NhbFJHQiA8 PCAvV2hpdGVQb2ludCBbIDAuOTUwNSAxIDEuMDg5IF0gL0dhbW1hIFsgMi4yMjIyMSAyLjIyMjIx IDIuMjIyMjEgXSANL01hdHJpeCBbIDAuNDEyNCAwLjIxMjYgMC4wMTkzIDAuMzU3NiAwLjcxNTE5 IDAuMTE5MiAwLjE4MDUgMC4wNzIyIDAuOTUwNSBdID4+IA0NXQ1lbmRvYmoNMjkgMCBvYmoNPDwg DS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9DYXBIZWlnaHQgMCANL0Rlc2Nl bnQgLTIxMSANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtNjI4IC0zNzYgMjAzNCAxMDQ4IF0gDS9G b250TmFtZSAvQXJpYWwtQm9sZE1UIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDEzMyANPj4gDWVu ZG9iag0zMCAwIG9iag08PCAvTGVuZ3RoIDM3NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIidySO0/DMBSFd/+KO9qIuH47WSmvdkBImAkxlCotQW1aJSlV/z12TBOVRowMKJJzlNz7 +fhcXzk0ck4AB7dAGc0MMP+0QitGmWIaLGc0TcGt0Whca5jXwKhV2claz9Ho7onDskYM3Dwse4SB uI/AV5HPWrgvTYSkmeYpJJxyk1pw132xicXC+N3bhqiMDG4MGCuoCWZiA2sZyuqe4S5Q4q0zlgYn rRTBzgu+HU8e4XG1Wy7yuoFJ2eQV0TTDG5II/9rm1eytWBXNAZwvKMolkFc3DUDWobiMrOludSCW phi4SQS7BOH/9fVhf9k1SR6bnsviM6/qoiGGcnwgkmoMmwU85Hu4n62JohZviT9Riuv3oiIW5xHZ h3g6pGMqWqZUCm/AB/NzADEibcxQzFwdY46qA3JOdZtzzNK2UK/8sAN5uitzENnx2J45bExlmTc2 ZMundH5Bzi7EgPnvkauzTydVHf4X8S9Jf23lxqEvAQYAaIjmRQplbmRzdHJlYW0NZW5kb2JqDTMx IDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIgL0lk ZW50aXR5IA0+PiANZW5kb2JqDTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE3IDAg UiANL1Jlc291cmNlcyAyIDAgUiANL0NvbnRlbnRzIDMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEy IDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0y IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUNCAyNiAwIFIg L1RUNiAyNyAwIFIgL1RUOCAxMyAwIFIgL1RUMTAgMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9H UzEgMzEgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDI4IDAgUiA+PiANPj4gDWVuZG9iag0z IDAgb2JqDTw8IC9MZW5ndGggMjM2NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iYxX23LbSA5911f0Y3NrRfeNt33zbTxObSYziWb2IbMPssTYTCmiE1G2Zz5jv3iBblCURDescpXF JhogcBo4QF/MJmezWSm0mH2ZVGmVCwV//iG3qXIqF4UrxOzb5Oxyk4nFxsuV2CwmZzeftLjfTFSq lM7EbLF7ep58lj9d3v6aTMs0l+J2nRRpJrv6R5tMHTw9hh+RaCNnyVS71Mg6marUyU0nSG2VGHg9 D7oimVa2zOD177/8fLhj6zfcB5NfkmrPVjLN00p2fpt4F1Zh+wrspaX8K9EVeqiDdh5+pt6ICQsV fv4JbqIfh2+VN6b7cKY6qwC1Ch7/O3s3UWJa6FRbA5BcwQoRQnBAPPuKsOcBdohfOY9qeOqBz6sM l4C9Tl1WmACsTsWHu6/1oktK8LJ5Ame1rDf/8svwYTCtFdk2wbARlSKreZaWJVrF4zL9uamdeZ0m iA2GozIlPzzVP+be+Golblo4MxDOVxvRfkkg6GbdwU+N8JTyR6I1bGwfQeWuWTUo+is45ndt8H+z vt+56V5LPG1ycjVT5OrU+6qDsyZzLjiLyVPAdx9q0d59xawoZb3AXy07gMY/+GwAD8DfqbaQF6J7 qDckwygNpCb+wCZ63WE4rl+Jpn/oWrGsvyVTg+fdrvvdPzC1nJx3tWiCE+vwzZ1d2oHA0N47kjSr oAFYTU2WIl46l8GtZ5+IZLJ7EH9KUibrYddc9B41iYXX66Zfb/E4KvnNfyqTfyZBHeMXPyXTLC1I 5Y68qr2iHfIXsiHLc0zfcAJ9utgiDydw+QAViuatXNc+FMj++ju92jaPwZdc1utOzPudS3GTTAvv sde4JzgswCCusTarcAYZHK33LZP9Z/xxWgge0Df49OwroOkWtKbDNfKMNNstqXa9LdogFuF3Hkyu VjVtXIqQK6AbRKQH2S5Il9wgCx1tb9q1PxRwyPQPbW8LcG/6Ly9b0tzuAZT2GxObY7r5U5j9g7C3 hH1hqyH7y+AhHOqyxtMuZLBX9OlpKT1zn569B9YXbk2S1nvq5GP/go7D+ewM6PrsLDA7gT4CHUKa Pte7TMWzrJAjtvSF2ueZFyNpBxTyALYLwMF5r/ZMm4J4B+D9vu1deOwj8inUu/9ck2urBFa716Dn /ThQOsBRl7tWpQOOIfvhoLbQRXzFPHShkDHrFJ7EHVrzpYkfCaetZR/eU70mxWVLtjaY3xDMnASQ 8vTq0Vts+/d+RaLWLw4tpOIETs+gNcKSOF1XGKFOgb1tT+oGSb2Q4vo71iSAkjjfpzzFv/cLdNXX HS6AyfHYX3Yff3VE2DF1VkAx5N6BcZvr/YbKcpVDUimttjtSUUU/MYhPz8hKyAKLB6zFgA16cD2b aNEI6JVV6pwWWaaxN2awQoOqFD/qyZfJxezIQ6OAO72HmekhGpxDq86mpQKDObgFXTh1pZj6/97g m2KYXcqd2CmVVmZ/Q+ay1MT13xDvfx3gDWLoeJkZq78mv5jFm6wHEoGxDoABI7s262e5z/LCJyJk 5SKUwnxZi91Z9I7hLwNLEDOwxPQH82zcEfkoDYZooYIPotUmRPt+gfVm5NW8m4/DBILiwgxiJsyY /mCeDTMij4fpqpKyPRxpGYL8LQws/27vm0WYKsahqoINNYiZUGP6g3k21IicCbVU+6EG8vssb8Jx zhMll56k/wZeA95tX1BQjQN3ZcUFTuJ44FH9wTwXeEzOBJ6b/cAzHQL/o3nxvcUPvtCsYW4fx1qw bEZiJtaY/mCejTUiD3TVt4tY2M4dpHa+a+c0Ft2EA25CO7tHEoOB69o3Fy/owk1w8YDzEw4qQ4uh 7uIcXsFE4QFm24uBGTU/8Oq4Ae7DnrFsSWIG9pj+YJ6FPSI/pUs4k+9NGB5zD39Ozfsy8X0bR1Ar N4s28TU2TjzLEimJGQRi+oN5FoGInCkydUikZne6n+X1Cw3/dDuod6P8OG7NsiqJmbhj+oN5Nu6I PB63rV5lVX9rxBvVeglBW7wB+aHYjPnUViyfkjgeclR/MM+FHJMzIRcHfGoo5PMVjvsOr3x4uTuO smSZlMRMlDH9wTwbZUTORJkd0KemyeBj8xTuG/Urd5CuXY9T2uYsmZGYiTymP5hnI4/IT+oh1u6z maXO+bHddnWSQfA5XJVGTcECeUBTsEWal0dNIUqfZYHT5sEH8VujzmAdy4skZsCM6Q/mWTAjciaN dHncD15pAkcXV5NmCo3BzS8Cg2FpksQMDDH9wTwLQ0R+SoO0Sh1eLGzA5F0yreR23TwCiVgaynyB HWFjIUIIigNH8YSq3iLUmP5gngUnIo/niCnN0c1S06ymrQst9Oo/V55cK/kesyaXNKU5mtJcmNI8 MY0KEqL2Uxr0YPfGlIY1e+QRM6eZiiV1EseRjuoP5jmkY3IG6dwNcWHu2d2ARkB/6B6A2qCJIbnB ZHYNA1ouv2+bx2/h/TqZYjfvRiDnfhSGsE+jPANDwdgnBuuCbSMkZrCO6Q/mWawj8hBhzpa8cTD4 uAF1VYSS//nCz4Fanif+53+JhkTe9BVPsFmu1k3G9gMSM6jE9AfzLCoROZOBpjzIwIzo77dVohVk Gl4IDF7GHJRyE94txv2hdMAMHC6WbRAkZnCJ6Q/mWVwi8lMahNHHDYIgusZrQwYTx3ZVv/SQ5H1X sK7iEdFsVyAxg0hMfzDPIhKRn4KIrsxBztAU8e4XP0bc+ilsNHbCfjZe9RY3x/QH82y8EXm8MnTh Ds+9v0ud3zd4f8zlKrHADzgYIA0r2Y2C1iVLkiSOBx3VH8xzQcfkp5Ckzg5IUisatj8l0PYxao09 CUajQj7V9DCiyjQvXMFVgc5ZviQxA1BMfzDPAhSRM1lhy6PZyNFspHQRWvbtuvM5kWZyJaClIH/I ObbpDC9mZcgZXC2PWAPuKRpmrQGv11uvdiyZkpgBLaY/mGdBi8hPog6j3hotP/0Kkzc0m/OPl+Ji 7gEL07eBRrQcl5hheZTEDBgx/cE8C0ZEflKJKbMrselwoVWEQxcG6hbn6QJqDTNmfh9W9ajSCmMq ttI0y78kZnCK6Q/mWZwi8nillcf0S1Pax/PbqzO4nWH/kxcfACR5Naqjt7pvxfJy9QYtx7R3tl+L tBcXLGPFpMGx4g06jHy6F79unJf+fwASbgP2CmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PCAN L1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTcgMCBSIA0vUmVzb3VyY2VzIDUgMCBSIA0vQ29udGVudHMg NiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIg XSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4 dCBdIA0vRm9udCA8PCAvVFQ0IDI2IDAgUiAvVFQ2IDI3IDAgUiAvVFQ4IDEzIDAgUiA+PiANL0V4 dEdTdGF0ZSA8PCAvR1MxIDMxIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAyOCAwIFIgPj4g DT4+IA1lbmRvYmoNNiAwIG9iag08PCAvTGVuZ3RoIDIxMDM0IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJ7Ffdb9y4EX/fv4KPUtCVSYqSqMfa56YJ7oqg3vYlyINjy/be2buuvY7b /77zRYorrXUtkCJCsTDMlTic33xzRqerxclq5ZVRq5tFW7S10vBHD3VZaKdr1bhGrR4WJ2fPlbp6 JrpWz1eLk/cXRt0+L3ShtanU6io+vS4+Z386+/ApX/qiztSHTd4UVbbrnrb50sHTI/+o3NhslS+N K2zW5UtduOx5p4TtPrewfcm8Kl+2pa9g+29/+fP+iRc6cMuQN3mbYOXLumizHR1TH/mNj98DXuGz f+WmRQ0Nc9f8syQQyy+af/4AaqIe+7uawEwwZ2mqFrzWwuOX1ceFVsvGFKa04JKf4A09hM4B8upX dLtjt9cFHClV3RSudXg0Hqj5ADhIO3I7P4XI1A2ItxicJbreUhBM4aq24SDYQn16QrurbPu4fe6u weWuKrOz7eZmjftNdvsiBy53srPdPLP+vYb7idG2Ir62hal78UZywMEZEn9+eYWRMtkdBsSSh2y2 vYGfEuKjdnedCi9bPnKPDB5+SnjZ4nn4fc2XFjbXm1vZUIILZgj7mvnEGsfW4A5Yw2fV854ulwIV BKqvstGJrrtOGHYYeof7RL9ObXkVKbs7MCYAqID9LcdkCG9rsknkXTLK16hFSZwE2v3jJbA8PoDp mFzdZsfEYLDYuc2NARnhGLk0vIiMnRxd/1Mcsd4wU8xSSNKqrjHzOJAuFrPkEXnCsWuq7IrfyC9N tt5uWDOjoFhR7yq7FhdUWdiBSqvgMJ/8dgkqGXTDGmoTPLQjowhLzotEJb+PnQhd34SjkMxrrGKD MjTbLsxdCF5UUt4KfmPDbdEY7dH6pmrfqFApQPJRUzo+hi5q8Cx5q3TsI6opzD8oZ3C9g3uFhNfk IUsbRY6hM/JMlxi/DAuOBTbGxKCYJgaF5Z1eglENegJAawwKvij53eYYevSmATdvOtnmqnCQmQkr eR8jhFnCEbqUbDsnnyJER4CYSoC2Uz/L9qX8CnfHgYUkK09ckl/i4c/ZRbd7IZY2e1QC3kLAHuUJ 9Tac3FJ5JiM7fQbpdS2n2Eof699k4HmhCW9HpUBG/PLHM2oyNd/ioNwH4fqUY7pw3iLvNbaWFm/L A2qoRzYO7qXHTkhQzVYDMJlfShhX7yQdet2CUkF/0C08Pm6DmGDnVkgbUiL1UohJFzTBUAAbdLGW b8kqW+/EOXfMLqhbAROdmNjhTRGVvxxquZbKvl4HU8Jvl/oH7yaR8vI1uLKL5vQ+OX2R9LunvLtW IVu2L1SwTbwhyCeieyO5t3t5lGRTkAcWr1bJuk3IQr75zKAkHglsu9uG2rgPsp7TYlHbjXiYQ5Lt 1G/kWk+R4HaEUl5zHBoCxl3cVrst8992Uj6wwcUFqRiO4UYm4fdcUNFF+31Um3C13HXS8H6jfANd Ib02YTO0um/023I9FxxX8ecJFWzfhTYR6Of17d0utEj2/UYFBFD7PZrZ99cl95JzPrrehJPSNaXV hCYV+n8XBfQ3Ak6VcrfpNlisLVv89+4Jcw6CSRdTQw1ZLLjLOXExDwONLgbYBWegV3js4z5NnoZ7 ymRCQH617dEC51MxvrCGLeF8BW/QbDyMY4UvDc7BRq3VotQwccLV7BqYVFQJHcoqbE5WPXWLGx6e zy6Aqa5LZG1x5L44A+aP8PArbjn1qoxWv6jPX7S6XlgYs6oaEGu4uZxAtgh3+o6UKKsGVQGXgRJl CXlvg/yHRelc4VEfDy606r7faFzhPG4EDpgm670Ngrhf3Lz7X6B+ZeUbUNvsK16imYdkGIijSzai Z5jlfogxUP074rLy/PlTWsgSOo3jMArAW5g2ICWJ3ULJuL0NuBA9blSFYwFVoX16ooRR00fQ+6EU Nu0HSq4LSz4sMdwgGSqU0t6bEG64XvzeRo/reQO8jE71Fj9eElViYILbWcr9UOzsVMEeVsciSOMB h32aav0G9EjKLA8CcUM7iVgIkIZG6dLK2pfyoyVbW9Q6+hLdX3LxeI0XFXLBveX3NmDKqFNv65YD FOMBN7Lfy0Ec9W16Yl/s3FQxysitFouHvIw6abkov2eJltBPXBrLfbGD22IGqoTiIbf/ZzVroRIP 1mw8EWo2lGjcCMHdFzs7VUwrXWZUxMH9ULN6Lx4xO0M8xkUcEjr0srgRq3pP7OxUScqLm9y4qitx /39R1aGIQ5YmVS1db0/s3FQZDZ+/M3ceh8i5DpHHMP5fhPH4LTCHAXxGqhy/BY7fAsdvgeO3wPFb 4DuqMp8BfEaqHKePmbT8GalynD6O08cPr8zjnTArVY53wvFOOH6RHL9Ijl8k31GV+XwGzEqVGRXz jFSZTzHPSJUZFfOMVJlTMc9GldPVAo7XpVMa/uSRQ6Br5SoSv3pYaKLDgLPUhdbg09XV4nP2fp0v q6LNbpfn+ZfVRySWzpZqaQrTAv/qpwUeL1s+fvGaQ7rW2Xp3dZe3hctOiEsXxrQmZSIhlXD9dfuy y5cwzvqseyKG85Xoc3G2IAVf1cJqy/MuFFUNLrVtyy6FJDE1Wu9qcQdtPCycafhCgduKJuQLAKtV +AdbDSYY+thW6LCqRkaLj0/dwtqW05KJILGUCwouOwpAf2K0UXEA7nomKP3WEkrL9eAaCDgyhQ34 InH0PhSzD0Fh1UWrLZjhW6/4GcwZQD8sDGQXzfdBlmksKxig+g24ZvDdN3xNwz1EykWvV6ItOFXr 5EBUjgFGyo7sJe0hHeWf9A48EtrokRGG5lroOUq+MvYhREjjWpWuA1HGDmQJUi/LDUQNwkEQ/Hmw n0gPyYYEMTp6tBFDMQzW72fKMN0GahzM+D2plcd1CZcRFBnkPAJQt4nklEpOrTXGrV+ljN7mQmrV Z0RFxoxAvUpXAZ1gQzJ97Qq5xk4xRDVYIv0qqBNsppGeLuSq8GNQcmZcCXSKC6lJRVTY4EegpKIs gjjBY6BTmsQKh410BEkRiiuhTrIh2fVlV5XYiEaojUpXQZ1gQ3KbmGJx8hmilkalq6BOsJmm5tFK yAYOj1Erla6EOsmG5NqnZDP2QNmqdBXUCTYDg45Oag7vlSGoK1W6EugUF1KTlHPtIa9W5M+4CugE G5J9b4jDKX+MSv6Mq6BOsBkYWKxLyQe8WpE/40qok2xIrhNTGuzxQ9SaHBpXQZ1gQ3KSdjBSVOO8 asijcRXUCTbTYHPpybQ/QiWPxpVQJ9mQ7BNTqjEk3adxFci3eGIDEprDaWgI6eneiytCTrMhuepL zlHDHqJS2GURyAkeA59POjECW/4IkYyOK4FOcSG1TKwwOGgMQBsaufpVQCfYkNzYlKxHxlMehUUg J3gMfCAkwxFMKeUolxrjVLoS6iQbkpNUg3Xk0saS3XEV0Le5kJr02tJDSxuDVipdBXSCzfiSv4si +YBLS6z4fiXUSTYk14klzXjwaRzFKK4C+jaX8S5NOBiQ3TilHFkeVwKdZENy0m5xDB/bX5HlcRXU CTYkJ3MhDJjt2AE1mR5XQZ1gM75KB0Mgj0efhuq+Xwl1kg3JyWQIc/l4oGwavKH6VVAn2Iyv034L w/14+qGbNCwEOcmD5KTbwnfD2HrPaGEV0Le5kJpMhqU+MPg0LZkdVwGdYMPPvmQyBPJ4oEQV+Z/w Jhn6z0giw3fK2Jmepv1+FdQJNiQnXdb6A0OPp2m/XwV1gs14n86EtjngUU/jfr8S6iQbkpOZ0DYH hh5Pw3m/CuoEm/FtmnC2Ho+SnmbzfiXQKS6kJs3WVgdGHk+jeb8K6AQbkpOZ0LoDo6Sn0bxfBXWC zbQ6nQkPJOm/2a+WFktzG7qvX3GX3YsqLPm9DQyEbKc2IWQVBhK4lRcZ5u/HkmVbfpQryyyapkRf SzqfLUvWEfPyIQny4kM6xQbRHkhkYlY+pEBe3CCD7rWIB8qTHF9Ql4x6dSO1arYIBxKZmOwPKagX N1IrQojmwHsSk/0hBfXiBhk1J0RzoJKJyf6QjHp1I7VKOchbXL+wgGx1a4W0s5zEw8KQvKubF2kV A4R4CmDga+5SQC9upFYkEOKB5SQmjUMK6sUNstMZBmHjjl9YkFr10LK+U5rEI8yQvK2rG6kV4wN3 IIqJ2+6Qgnpxg+w14wO7UZovLEit2F1R7/WWuM90ybu6eUEOum8CHrhL4ulqSAa9upFa9U2AjRN+ YUFqxePA7EwlZW5TXK3ZtU197gQ5ahJXtCv3+8KC1Cpp8ilSPN+1nUlS3LwgJ90J00ZL7gakVdQs 7lHKPBzWfWUZEW9OpFS8LGzc424AOeu8CBttuxuQVvUxv7KJq56Uila5jYzdDdAYzZ/sxg/uBqRV RMlu9OpuUPJu6jRb378bkFb3mY0y3Q1Iq1iO2Tr53QANakbzMRYKX8LHczV4cm4+6F/Jx6GM1F4/ OMXqXiOd8slPWFtw/Nt2j1AXGqeo5kb6Y6L0ejKJTbIQ+HeUrpQofZ88ijX24KoH9qplyATzASCi fmvUQqHIhl1irph9oWFgaF+Vj4wF2UZZmPaJ9NrqgxR2G4M+Kvq3KRDoZFstVMjprmJZFupRW7TX u+q/fa2a5oAm9QVCRGjn8tTdacHWVJVNYemEQTYZ6oLvx0gVQqbBdlAspCbLyR1bEPfCERrEdlB6 83kBa4a2YCLvd1oIsk+5ECyjbP3qutAuFdHO105fac9x21ZLg1BPkjuED3KSKbX6WVvy9WhIdvZw tfTt8bRTuFvy9/uQ6ugX1spnKbBafW/Uzesf9YQ5nX1amEe0ujMW9cY8gqGmNySD3rxIqxqjj4d+ Gkx6aCmgFzdSKw7mw8Y8ChLQCzakoF7cIDrdMr3fG20ADmaXDHrzIq1KtqJd+UgB4i2KEMSLD0Sv m6t3W/slIL6hLhn16kZqRdW83UgKIcWHloJ6cSO1asYet3ZdkCyNEkMK6sUNYtA92sPGXwjJP7Rk 1KsbqVXrLuq1uRNSfmgpqBc3iFFTO29WtlOAHI19QzLozYu0KuVcPkXVczy7FNCLG6lV93dp40aE xPHsUlAvbhCTflyL+hBVz/HsklGvbqRWFNHFjUkVpMAB7VJQL26k1tQxbASrIPHgO6SgXtyIIjh1 FL/xLkLiiHbJqFe3Tjyaeofk97RLgfzMB5LRzNM5aiIrJA+HQxLk3Y3UipA6S91xReVrFyGQFx8i WEYdorwNOyIfuksGvXmR1qpTEA1eQSPPWEMK6MWN1BG12myH5zxqQiAvPkQmjSo2mlV2SPfQklGv bqRWqUYsZwPFOg80KaCfe5FW9VpL8+QO6h9aCujFDVIhG0mrDyG1VPFDMurVjdRBnSTuxCc6vqMu BfRzL0hOJ5xlhruB8sm7ZNCrG6lVu7X+QHyi55N3KagXN1IrXmjdzAsrauCjdymoFzeacxQxLOqd +kSu+yEZ9epGasUMrT0QyhjphRpSUC9ukILutxYP7Idf0iYY8upDatVty9Cxnz5VtCYF9HMv0ipm aM2B+MTMx+5SQC9uNIAqZljUO6GkLdY/xrs6kFplG+ZDMBOz/SEF9eJGatVlMR1IT2K2P6SgXtwg Jc0JMR4impjuD8moVzdSK06I8UB6EpPzIQX14gYp64Qrg+5+TczNh2TQmxdpVbNFf6A8ian5kAJ6 cSO14oToDlQyMTUfUlAvbpCN5oSHJGVePiRBXnxIp9gg2gOJTMzKhxTIixtk0L0W8UB5kuML6pJR r26kVs0W4UAiE5P9IQX14kZqRQjRHHhPYrI/pKBe3CCj5oRoDlQyMdkfklGvbqRWKQd5i+sXFpCt bq2QdpaTeFgYknd18yKtYoAQTwEMfM1dCujFjdSKBEI8sJzEpHFIQb24QXY6wyBs3PELC1KrHlrW d0qTeIQZkrd1dSO1YnzgDkQxcdsdUlAvbpC9ZnxgN0rzhQWpFbsr6r3eEveZLnlXNy/IQfdNwAN3 STxdDcmgVzdSq74JsHHCLyxIrXgcmJ2ppMxtiqs1u7apz50gR03iinblfl9YkFolTT5Fiue7tjNJ ipsX5KQ7Ydpoyd2AtIqaxT1KmYfDuq8sI+LNiZSKl4WNe9wNIGedF2GjbXcD0qo+5lc2cdWTUtEq t5GxuwEao/mT3fjB3YC0iijZjV7dDUreTZ1m6/t3A9LqPrNRprsBaRXLMVsnvxugQc1oPsZC4Uv4 eK4Gz5qb5ep/eyhdpO76wRlWtxrpkE9+wdqC49+2e4S60ChFNTfSHhN94skcNslC4N9RmlKi7H3y JNbIg6se2IuWIRPM+4eI+qlRC4UhG3aJuWL2hYaBoX1VPjIWZBtlYdon0mOrD1LIbQz6qOjfpkCg k221UCFnu4plWahHbdFer6r/9rVomgOa1BcIEaGdy1NzpwVbM1U2haURBtlkqAu+HyNVCBkG20Gx cJosJ3dsQdQLR2gQ20HpyecFrAnagom832khyD7lQrBMsvWr60K7VEQ7Xzt9pb3GbVstDUI9Se4Q PshJptTqZ23J16Mh2dnD1dK3x9NO4W7J3+9DqqNfWCufpcCeLz+/UNa4R+Fp1A+otmNQBUgOUerN t5yokOGtIdYKC/VQ8kIsKCBkJkjw1IJk0hlGGdWHhm5B8YasP0P9NevNUkKD2uzo6uMrB5RGR0Ir nLEgdXKGcdfNohyG9/YxvVwpSX26pO5mDAx192eUNuv0B7IttCMfQLRJ22nhIu19D/KC9tuLQhJ6 DkShkS0HgrQzfXkbiu+Jk6fXZOTACWYy2sKqS4ADgoV/olFhpQWnU55c2k1JRA4opmdwLZy+EPpL t4Foky2s5s07moZI1nkoOokiFbulwa3slNnLorGsAoUUiOqSPCJp+1VHTIMero5FTD6ccbTtrMM6 EdJFdhxLQxXJA9Zsv+qY7tOj2bF4QCN5xNL2q45VfoQqAmcNuDOUMl9VQKyIkq5DBdoVySOUtp91 UGe3NzUcAA9QcAz8ZL6qmKdSj+pQnscef8yF2X7Vlb2+Guo8+8xyxNL2qw5JpYcNpG2RPEIp81nF +K+Ukh3J20eVB6TJfFVF/oobscqRoeInUNp+1ZXVVzPenYKSeI4q8oil7VcdchyhzyKP44sw2826 j+V3fde/MPnr/wJiHqZSgaErXImfJ3mdfrxlP96yH2/Zj7fs//8t+/QJ+7m/FfTHc0+biwxl2QdP DpU2G6HRvv+WoaDRd2hsXcbQsiDDh5GRBoTgpzb/YZ3mIEUZrrCOtpB8t+CBEJITi/I1/m3lROVl rAuF3odpoVFZK8NKRJlLtwXkQEHM/aNhQui7at/oC20XSO+z3mY/2TgI4HRUqKPqCAa0waWFq0e4 BZTawxRyI2dVl2KSzHu8gOVITs8YYyHJPCEug/oLKIKVmVE+i1CySG8Mwc9bRwjC/OVwCGk+PkIW CwkQoumXwCFEpO6kgoxo52tAdDIe1XvC8rWGOf+Wix4IfaF9Q5Jl7KIt9H3WfNMHyWE6atsV+PWo LVzQBrAWUCmMEXIpHX0py2hoZMCcyvMpr5bBR3vn6f9LHVtc6njLmVoOKqtCWgrZuKWQ19SNYa7j JffDUj55LThZSCUJatRrHquaXRZ6PY0ihfkhwKkg+xZHzob57WnvVz9Ve/FGPUqgRj1KtUnkWnH1 2JaFsJRjTXJVjna6efHoqdHrVVWj1OuoxprUPQElV1Qx1uyCNB99JLkEZ5RBS1lVezWpVa0tC3JD iKEXm1nLNa8VnufPYjvseCXiWn5uPtz6EMX5qaqZqkvPuOW1C2kpPTe9mP09nEuKa+937y+50IXM s0L9H3hXtmjCw5U9lBC9f4xR4pUyydrH+19eOKfS4/23lz99++N38N/+8eu/v7+WQ317/PSvX//2 z4/vrxT7b7/8/T+P3/8iql++//n9Dy8/va9d2+YSUQoxMp/zht6XRqadw/8yXi1JkqtIcP9OoQu8 Mn5C6BxziVlkrfv6QzgBeAoUPdZWYZ047uIbhLe1aOBvbUg1XUtDbHs4eywNvi3GfycpJjkaVaV+ pUhD8m1LRkM/spvvfGm8Z6+H9m+d4NVOSP9YvPv+qdRs0OSaXBq3FLk0+UuPjG45EM62c3xd4zng ZdKYgZiR9idjH7Mu8ijSQi0i8Wyne1Lux0I1Df3MlaT6nvHrY3V9Ht9Kj0+F9FDO3w3Xz/xSOP4c z1P1Sw26oWPRl4a5LY+N+3+OzePwPcbxWavWx2fPKJf8Xy8zkxsgcMsGDQ5yfyfc3KmTHZxRVQ2a wO34NLh2XkXLwVFF31ky1UCf9Iuil8syo17+N45gJ33NSfsiiXUcUSUNmsB3GHC6pT58qmKEGlTS 4ER5QuclSUXOwiKJzRkRqiZN4JwYDhvV6+CoqgYt3kkLggZfkiyeqtEfHKFq0gSOc81T/ll3Kp4H RxV9Zwl6BUbdRvQ+OKqoQYu1unG06KeUME/VFA+OUDVpAidadHGsi+qJ9RxRVQ2awIUWPUqmX1Sx oCOqqkGLd9YKpsObhHJiRUeEqkkTONFHwyahZCzoiCr6zhL0ovOBuu4pemE9R1RRgyZZ3QeG/TrU C+s5IlRNmsCJDojbpZULuXREVTVo4wVqcLx3maUg+Y2oqgYt1oqekm7Ew/1UxdZrgKTJEZiSbiw/ 6zhRJM2oou8sQSnrxksqn4fohfprRhU1aPG+OevGLGX8U1VOUw+QNDkCU8qNeZOpL58Ojqpq0ASm 0qsWQWtOuQImPqKqGrTkHFcbNa455QrnwVFqNZsmMFUbNa6iUe79jCr6zhKUio3qyNK6/QmbNKKK GrSabWrimnDY5JQrYeYjQtWkCZwLw2tOuU5MfURVNWjJBU65ERXkUzVj7iNC1aQJTDk3omJeVFGn j6iqBk1gSrrRLZKXJKgZVfKNk1zkdBvuTfGHRNoD9EyOwJRrQ9mk6Ks0uR5V1aAJTPVGdSKbfHJj 1iOqqkETA0j1RoXXlCJjbH/QMwnTUDY4b8q+glJ/RlU1aAJTpRHOtewrqPZnVNF3VnJnvQWMrgNF uT8jNC2WoCctdtqkkoLSfEYVNWgCU6atNvJadr6gNJ9RVQ1acpkzbXjYwaaK0nxGqJo0gSnVhp2L LKjNZ1RVgyYw5dqwcZEFtfmMKvrOSu7iTBvcJkEXlOYzQtSkCUyVRth5yZKwSyOqqkETmEoNv/OS BQX/jKpq0JIrXG34nZ0sKPhnhKpJE5iqjQqvRV9BwT+jqhq05G72hX61k3/pITB5QL9xjgWOYUaM ymIJSrnV75xjydjmEVXUoCXvOMP6nXMsKBpnFFWbJjBlWL86x7/0EJiyqd+ZxAIjM6MOy6Al7zmf VngjiodiRIhaLEGpgvCLRbQ7CErVgt+5wVLwzoyoYzJoqX6Faga/c4MF3mpGqJo0galmwA4+52r2 EJgc3M73lRtPFe7qnfqg3klJtsMR+rz/dgdBKRVuDF6BtevD0gNhkBIO3QBXe2d3SPjfQHc+7oYv bOO6nR4Hi5Vwuwh9Vl12h1RvN+W6c02GZgdB6Q1frZndQVB6rBcPZuICsm1aKiS7Q6rZkp/fpRSy OwhKRmi1T3aHVF8VcjyrT7I7CEp5ZzVEdgdBKcP8zoZaL+Tj8+zwweE85B8OZAeDvAy/OGLtY5Ih QPejB+TqO5W1Q73hH6onojxZH1RYlzbUgu2DmrMd2yiX6IMavK+naxrTi7Xf05rm1uBGwrpkGPG+ R7LXhovfT2nwfFypIYhRY43eML4SIg+iFp6l8ChDaN8c86gNofBMa1l5B14LqTMLr1Zt0MXR9awN 7mvBpYrE3PuWBGz9Z93hSsVzUH/frSFqhzpj/D7HRxMkq0NrE+3DqsayOB549a9Fp9a2KLqW3sdc 41yNtkd1e3uPtjwx9wXHr0sXq6920mS4NPQdG5TZMH2GfuIcV0sb4niFdFSPo9XnMc5en+k4nX0t asP3ao0T3tdz3IG+4P2S9B2Zt+jrnrVL+CNPevurV/FxXs+HhxKY8ue581DZyes3o6oaNIEpr54b D5VdOTiq6Dsr3oFf8uo6nopeHsYZofjOEYye8XPnnrLHOo6okgZNYHre0849ZYxQg0oanHhHPr9p Z51ywOaMCFWTJjA9+hV+lgWidB0cVdWgxTtxLZBW61SVojiJGaFq0gQmZ5Q2firH8+Coou8sQSmx p52fyvE+OKqoQYv3ycYo7fxUTmL6ZoSqSROY3FJa/VRVOrGeI6qqQROY3FLamax8YkFHVFWDFu/M VUmKu4RyYkVHhKpJE5iKlbTYrCqUsaAjqug7S1CqYNLOe2W43hlV1KBJwUAmKu28V4ZpnRGqJk1g clbJ7dIKXOuMqmrQBCZvFXeOLMMhzqiqBi3ehZNuXE1ZVcLWa4CkyRGYkm7cGLUMQzSjir6zBKWs G1erVusieK0ZVdSgSfFHWTfuHBxOUw+QNDkCU8qNq4EToXRwVFWDJnChj56bnHIFTHxEVTVoUupS tRFXuydK58FR/IJNE5iqjbi4wCoU5d7PqKLvLEHZ+q3msAolbNKIKmrQpLgnRxjDJqdcCTMfEaom jX1Lg9eccp2Y+oiqatDEd1DKjavDdEh0HKFq0gSmnBtX4ylK98FRVQ0aOznAi+QlCWpGlXzjJBc5 3YZ7U/whkfYAPZMjMOXaUDYp+ipNrkdVNWgCU71RLcMmn9yY9YiqatDEYVK9UeE1pcgY2x/0TILA VGmEvCn7Ckr9GVXVoAlMlUZ1R8seFVT7M6roOyu5s94CRteBotyfEZoWS9CTFjttUklBaT6jiho0 gSnTwgquqtfBUVUNWnKZM2142MGmitJ8RqiaNIEp1YadiyyozWdUVYMmMOXasHGRBbX5jCr6zkru 4kwb3CZBF5TmM0LUpAlMlUbYecmSsEsjqqpBE5hKDb/zkgUF/4yqatCSK1xt+J2dLCj4Z4SqSROY qo0Kr0VfQcE/o6oatORu9oV+tZN/6SEweUC/cY4FjmFGjMpiCUq51e+cY8nY5hFV1KAl7zjD+p1z LCgaZxRVmyYwZVi/Ose/9BCYsqnfmcQCIzOjDsugJe85n1Z4I4qHYkSIWixBqYLwi0W0OwhK1YLf ucFS8M6MqGMyaKl+hWoGv3ODBd5qRqiaNIGpZsAOPudq9hCYHNzO95UbTxXu6p36oN5JSbbDEfq8 /3YHQSkVbgxegbXrw9IDYZASDt0AV3tnd0j430B3Pu6GL2zjup0eB4uVcLsIfVZddodUbzflunNN hmYHQekNX62Z3UFQeqwXD2biArJtWioku0Oq2ZKf36UUsjsISkZotU92h1RfFXI8q0+yOwhKeWc1 RHYHQSnD/M6GWi/k4/Ps8GmHs56cPwdhQR6GX5yw9i1JEGD70QNq9ZnK2qFe8A+VE1FerA8KrEsb ar32QcnZTm2UO/RBCd6X0zWNacXa7+lMc2twI19dMox43yPXa8PFz6c0eD6t1BDEp7FGbxhfCZEH UevOUniUIbRvjnnUhlB4prWqvAOvhZSZhVerNuji6HrWBve14FJEYu59SwJ2/rNucKXiNai/79YQ tUOdMX6f46MJktWgtYn2YVVfWRwPvNrXolNrWxRdy+5jrnGuRtujur29R1uemPuC49eli9VXO2ku XBr6jg3KbJg2Qz9xjpulDXE8Qjqqx9Hq8xhnr890nM6+FrXhe7XGCe/rOe5AX/B+SfqOzFv0dc8+ //ynXkFXv19LtfYuXDp1EOQelqGgm1605uxHoHlD3+ataeKhkXUiQa77hxqUtZf56tSyTaS64c5f 34jjGzrOpDvSfvVHnT+waPRiZIyzN4xx7mWo02Oc1Tf09a7tv5S2Rpa69RzojkynEPQDq0bhBf5w w5tAh9vwkEh0hHIXv3YL9pZXsjacc8dr/+u5VauG70PQlRwNfSVfZNzrjtezThss38gjm+ttyHqB +krWhnkE9hrnmGvqN0ob3gQ6vKyk+zmTOB6J8DzxDuNFylIreBDqm10JDzC0elyS3lDDGpxX3Kp9 ExYQ5uhnDi07ebAl7sWo/4IByqR1yjQl7rWo/4KhYJF0NsRQlkrcizHhAfpW+Mn71dWuJEZA4k7t m7CAqKt/pljBmpWXNfvqv2BSWeEV/B/71dbbVm6E3/Ur+HhkVNpz5Tnnce2m7RZpESBCiyLog+LI trq2lHrlDfrvO1cekrIdJ0jWTJYwLIm3meHM9w1nnLCOWpTuIcv8A0eLNa4Nk9PG0hr+vF+Ytz9a IxULfK+drKY3/HmfrGD/0VpPilqv1bCV4c/7hfkHjhaxlC6Ruk4a6b/f/eH2o8Wa3FlpMNGe+6X4 G6PFm3iCcsDHN109TVBpSn50p8UKOyHKE5omcl7JeSXnlZxXPiGvPJZOsNzHEPO/FPzcPUE1RTWw NnmWOwjXBVppMVyfaKXJc51kr52k9ppQ1NugG+21G9WWbZDmyLW4g3a0pTSGA3dczTjCFXBipFEv KnhkdY0buGaspOE7mhi4aZwEuAmVP6CrQgvK2EaZ0Fv0S67CW9ngHDHdW2p99YyV0tr5zmolP3mX e9HJ/9LUcHS6qYym9myaaPz92iA6cdpCOoXaZDqTtA11Rmuj6q7VRPfWVtc5pum4bJ4mrHM/O7fp nS/J/W3bcotyPCEhbJsxjOkkYwxUjJFJ7JYmRpx3Tcakc4Si1rlK7+05c4x8rb7TaCh5fHJda47F 3mHgHAS/IxJWdcRC6UQnGrou0fo89ZAkPJ1YGIOxbSO4DhEpOQQe4NuIEV0dcYac6tMsmmAd0wnV WTof21Cnyx0T2CKzXf7Ri6knJpI1kWsCxyljnGs7vpZPsjaIYifo9UjXBjhQCQ4pjpWOdhHnpFFV MMoVHOX0jk3sBQdw9ZPDv3jW8SceKwE8TtpQpIS7ifHgJYIhohAb5VEoTjaMSY9BMYGa0LMO9wEz iEKnq9kIr/dI5TP/aiyaAmVLW5UYgtXNVF2/Kf41r7pif3c7XwAyCvPiv3fb9zfzBSivi83uYP6y kaXN/N+rv86qbtn0dqTqZGh7s/ojCFud48eHWWHmq//MFpCM+qGnErJretrDKz+sVlg8rS7QRqsm whRcoARomqavMCmihcuyhEuC5AX+bCqU/6YwZ/vdxfYSzLXFet4um+Iwx3q82O53pqaJ5Rwe9aKa L8A5MuAFQxcAG1pnQ+CnyYquWZIRrJqswF/VyEacrn+ZL4ZiO6+XXXGOPw197udQ0xQ7MAgt2m1o 8rCdL0bY9+t0BE1uYMf/5hUEDuxaVHWxPvD3yzU5361uSCjFYJCtDX99mFdlJPGKNps/zRcdhO8M JBXmJ1nb0dpWt27X+msfaFir/e/MCn4BWMHR3obLzcHIz/2dE7a7lFPukOxZX1zoHs9dhysn4vLK rPUsO6Ax4N66lPsd6IRcjCJYIrD6rhkRWA4dEiLLIXq9OdyRVFu8B23yc2PmoOCf80WLePhxjhj/ u3m/J2PAi78waMAH7zCiFeC4ALzRBWxBsKONG3OQuasNG/23H8FKuM/ZH8TftnhF4tWfFvxJO1/x RnR6W6hixLAtzHsZ79+rwTJxDQ6Bx4Ix0YofVidye7z8m+JMLe2cpS2gBwV16HH3U+7byn1B716W ECK0V8ZyuRdwGI5UkPoA1QcMD7jGQoDIbAoRyrni4yJ1L8LEJl7cELg7vgisrmM7tzvW+W6rl9Hv DQnQ/buD6rl7u1Nz3YUiB1XsodM74mIN7qwhBO8MXwrT32GjsSftiggjsxuK1uFO42Le0T2sBmS3 lgXKnAT1oTgXiS6qh71M7a9Vm3wzGsx+Jx6fIGl+FhzuaMte9CA3AMIq5srNm8OeRSBP6QdMeGjV jQI5QYVVJEaO65RXNdPq7IqSGlDxZ6QoUhJgt9NJznW2+FW+UUlLPhK//mBe0jc6CLzmhLzcXl4d KKmK/3eUFDhSLcIfxZk/s5F8+nJB0RuLF8wxwAwnvoYSn0usW148MJdGwlNbrMVkjDt+Gz+3tNWU W2p1QdmxD/6xuUVs1i3DuFeQ1wTySkBee6sAlorBj6sH9JZl7xBDNrK8pmVZZElmP0n2ZdwuzSt8 hHCnfFHi7QB2t+iDVhJvTe7C9CtyzcXtfk5guKGcAln3p932sF2L/MNeftwiklQmm3ZLmDpKwfH7 /2KF9cWyw1KeCvgSC5jKVJg0WkOVk4GAQldwu5ldgHOtbaTqr8zrsxlWUuaD8Q6WeKSpoLKipgmO nZ5Q04P1kMiFxqAdqAaroBbjpkQn4KJSGeqRUlufQAaVUF9F7tsnyYVkUg7+ROi6z7b30+WCva5I xMoUS9cKMA9dLyiAHyMeB5hrNYzFrj8u7/UPlpU8gd0ATnQYUJzgzkV0XMdK+abJGAKOrEkudXs3 VO63tEm73aYHVwcTk6KBm46aeq3KtXfONpDFEwM1hJX2lJHa5EwBp/ImoLREpyy9aCgMvfEYBAPo w67WcFXcmE041QlScR2pTMoKS72Z4OqG+r+29aOA0gZ/AvQRKV0UnBqNE7wnQ4BNeAD7AL2h2tRM gRH8UUrRxQeZ3EiKjZksLncI1XXFtKNtoCHyxG+q1VGFnPk0hkJVOfjObKEEDgJyzFCdcDsCtcmZ opxxr5aLhaOdEtVNKOaeztRQy7Nr7iXPHjFRaQVAC1PzY0zkeDjiPczEQG1qpnxSsZhrwmetCXN4 kg5PLtlzyZ5L9s+2Ipk6OSFTqlyy55LdPHvhnEv2lEzJdUauM3KdkeuML2pKKgROxpCE6JuQKYlw OA0rEqJvMqZUuWPJHYt59r4hdyxpmZJzQc4FORfkXHAyKw0oKmtTUpFQWlbCbgP+9dYsRsTi7WZ2 4a2XuNJUy8EMKApWT08m6LnYtgMzGiDYEJ514qg9YInXsQwhzleQ+/ZJchWLbiL00Gfb++ly0d4c npTDA1QSGoUN7H0vXS0ZLX7pYv+4lOd1kMzlppUOwj1+gVLJM6kYEjavT3v6uigDtrVkr4efvkG6 QtJyHatNzpSgi+XolKUXDfcSTuMxCMbHH0L3SkgNFahMyoqgefWfRI0CShv8iceeRI6TqxwefhID tamZAiP4o5SSS/ZcsueSPZfsuc7IdUauM3Kd8YVNSYXAyRiSEH0TMiURDqdhRUL0TcaUKncsuWMx z9435I4lLVNyLsi5IOeCnAtOZqUBRWVtSioSSstK2G3Av96axYhYvN3MLrz1EleaajmYAUXB6unJ BD0X23ZgRgMEG8KzThy1ByzxOpYhxPkKct8+Sa5i0U2EHvpsez9dLtqbw5NyeIBKQqOwgb3vpasl o8UvXewfl/K8DpK53LTSQbjHL1AqeSYVQ8Lm9WlPXxdlwLaW7PXw0zdIV0harmO1yZkSdLEcnbL0 ouFewmk8BsH4+EPoXgmpoQKVSVkRNK/+k6hRQGmDP/HYk8hxcpXDw09ioDY9U1IhcDKGJETfhExJ hMNpWJEQfZMxBUbwR8WJLj7I5EaKtZjJ4nKHUF1XTDvaBhoiT/ymWh1VyJlPY6gF3vnObJtlFwTk mKE64XYEapMzRTnj6l8XC0c7JaqbUMw9namhlmfX3EuePWKi0gqAFqbmx5jI8XDEe5iJgdr0TMm5 IOeCnAtyLjiZlQb/qEBIpdRPxpCECv2ETEmk2k/DimQK/aRMSYXAyRiSEH0TMiURDqdhRUL0TcYU GMEfFSe5Y3mUobljyR3L76Rjybkg54KcC3IuQFNKg39QIPCP12dUmyINezyNtsl4QAMMIhLRNDRY haLddamjczIb/S6rVUNVjpyUEcuFvTrGcBs92UMOcGJpcD5Tnbym5vGxwNjz2duTmacH0AK0qCzg AO253cxOT9x9RqSFd78ROxl3v5FcpIbwaLqfrIomOakjkjvdbwCnu+sNHRB8chuNpgvKqjqcDgbW BhccpdzW+44S9umE9a6ny69nMN82Rj+7uqbwL1uLQ/5sehtAYZSMPUHhs5HgAYGkBkCwHhBaZK5D Ao08KPDqhAXrYUHkxq5iKCwcFi7g0kPXGfcJIcVKGcQgbeCMwz+NIaXUPj4q6+MDRgE+Kr4oJms5 qaNywj+Oh4EhIf4C8RMBeOQBhFfFIjkZ2HtO+eV+CBzd4OkIdzdw3vQADhJ8+z2/8Ciwv5owzQd9 W78MvnNK+72ltBzg7zzA+c3Kb9Z3/Wbdh+8M5QzlZ4ByDsA3nkty/ZvLo1we5Tclp7Sc0r7ZlJYD /J0HOL9Z+c36rt+s+/CdoZyh/AxQzgH41nNJX7VGP21FuaQuoRABi6qmRRdWHV5o0Qxoj5CxHnG/ fNY9PqZ6arTL0cohdwbqElAykCr+rEJNtP0GJrqlpYl+CW/09ayuS4rYNFENy7F2R65jGdcY1K8i 9y3eoYFKSD/rke+NCQ721T2ECP879JpeeoRd7rO0fEKMgTQ3YIlWVyUgyE1wYP7PfrXsyJXb0H19 xV1WL7qi92M7jwSYZbp2g1kkhjF20I0BDCf+/ZAUJaqk0o0HcDA3SMEw0aVzeSRR5BHlIs5RrPWR wsVrLCF+a5vI+fKVe7ohoFDdP0v4TiX6roTvKybC7zljXgcCjt3dUHDSJCR6kwUmJq6HoOlGkA94 oIRqLxvz5YaXN1BpsRJNT1sGCu3d9dbDTljzbzJgzcWVncP1lLqBR5E9iuxRZP/1IvvueoKvfQAe +Md/wi0LSwBWrQI0ELCY69tJ0Rf0JlQKmoLru9PP55f3T9AhnD+B9ed/PUHnGc916JfrTyc4hGCM 3fRFayir6w/kDQV9ZZ60Xb8Az5+/B6d43l6+PBnoWc4fPz89QxjO756e/fkDUWHPru2Gw5CLSPWM DF4TV6F5eXrGucEZdmrPv33626/vyfnHK68f4gTn4LYvG0RD07Wugy3NfxvwDiJL8bLUccwDNbmc caVcgrtgyOW35VYCDgNbi3nAKmytygA2aVqlUjkyEPEJgF9kyNw7A6WDooTAJw2JV7KkXlZBfcJC DKS8tdi2QWRSqhoZAj6CUgYFLSFJJSSQgzg1FpGqjtUPJYPrHSZTJMcWikqbMs3byTpHqWtsxhfI qwygeODv+jlWiOkHqDKh5L8t4d/LkiMsVg/LLbGeJ9CK2sg2ICFJRZcGjnHV3463LL7UnDVQWfg1 ihgmmoUNZxqAUsYcsOCW3M1ApGI3VpWssaC0KvVfWA0y0Ehfx1nK1v7AmQN1+MZixeDMUFyU09Dq p3L6luqgG6i8vlSbpXDjQMRU7pdSD6aGvczyOk57uKXoRBJUKqA/Dk3XhyRa/a3p9jC0QByAW6Ec Vz0dEB7nupq6meEPnNQY0lKOIAa9PGcxxqR7VjvS0m4gXGzoY6wyH0s9BW04N2vmaUv9gnxxO+3R lgLXAGtZKxmKMa5JseZ8y8KkT/uTvJ120IgDLKWWDIX96yrVwE18t1LbF3VttTDbQD3c22kPtxS6 Hu/Vb40+FKy6OY6WnPU45grmfG4XWBuoJd1Peqx1tMKql9pcz74F/qvruZZvzc820G65m2mPtpTf 10Q+esXD9YqP0/tfPr1Hp3+E9vpAS3l0+o9O/9HpPzr9R6f/6PS/eaf/6DaOcMUfaCmPbuP/utt4 KMFDCR5K8FCCx7vjPy7lOM3+gZZylH7/KOs4TrN/qKUcqIwPtJTjlPGBlnKUSj7KOo5UxodZynfX U7ooH/Km4B//WQ5Ahc0oD13idn07KcKhqXlWF6Ws3q7vTue/fPz1+cen6z9w0DoTtmd90Vn77frD CT9zFj/7+fzy5QkS1J0/fn734SnDH396+uX6E3yiNbB3TkTuffH662///Pz0DH1rPL//RA4/Xnkd L9+DM4Thy3YyEClMfR0ttKcQS5NziSXkhqXccKHEoQy8nRzoEGagTvqCoXwBsrDV/7BHnTxJmfYB A+U1Wo219+n9CU9AuQbChFCWyK99xGC9dl9MA6EE/oM4hVIVxnnqtnUM5anRBoIDwSOSaZqegk5T XbIysIuU01b+ht0M1G8niDZ1wm0unVwJCDPJ71AKUOdEKqYDBAYHDNRscmWAFmc8ZaN80BbHFONq pw3T8t1W/+PCm4stPb3EZORgXeg9hhjZ1p9D5jhI987ezGWKcPdzlQ10k1F99dz+5oQKR3kM3KbS WzfAx9iCPQ3U0xiP62tyZUi4YRl3c76f1VskeoYnk8OcR3drOhA0qYEU0qDw2MRyFS2dEKRNFRCv wIkxbb1lxqWTTqHsuYD4zB0INZaGWCJc+yBWcp4whXfxSEjRa5YJl04IxtCBeloirY0N0y09dIp0 xxXQUZqOdHQczRLjjhOCtk3nsH2bGOPWW2ZcOiEoVQ+gno4Z7pLeMuPSSadE3QKD8TIt0fqtt0S4 9kFMNAWuijAds81bb5lw6YRgajkApZmnY4aLsbfMuHTSCbqZ0IF2YvQUv2aJcccJQS8hdiifIyMF sFlmXDohmCTGpL8jI0WwWWZcOukMQus6cCIMFMBmkXDHB7EgIYbecjrpSPFrlgmXTgiKZjp9o5nM SPFrlhmXTqj1opkAzkIbSRCbJcYdp3Z7FFDdEdpEAtYsMy6doGfrRBMeK9Om6YTZENvaATERTLhA Z5WlXkYsEy6dEBTNBHBS2Ug9klhmXDrpbDvNhKt1ElrKmGqIbscDQdeCa7E5nejc1ltmXDohmCTA 034N7bRZprvvobPrtBIeF9Nejd96S2xrH8REKuHlMelrtFjAYplw6YSgSCW8diZ9jY6OollmXDrp 7DupxPfTtGlH222WGHecEBSphHesn87Y036bZcalE4IilVbP+or521tmXDrpHDqttHrS10g1LJYI 1z6IiVRaNetrjKgxYplw6YSgSKXJs76SDFbDdEsPnWOnkwBO4hpToaqWGHecEBSdxPflFMNMm22W GZdO+NISrYSH6rhjXFr5T1Trr+XNRliYlTVRby2WCZdOCIpIAjgpa6LmWiwzLp10zp1OGj8ra6Lu Wiwx7jghKDpp3Cyuidphscy4dEJQpHJShkS9sFimu+9hFLQnEl6LD8mBjhphsfg03XNC0Et4Db5E R0a/9ZYZl04IilIaPctrolZYLDMunWDxnVICOAeRWmGxxLjjhKAopVGzvCZHB9IsMy6dEBSl1GgG QuqtxTLhysco0wklYGompBNplgh3nBAUpdRpltdErbVYZlw6IShiqeMor7u4UbbTRQAnMU3UmIul 5ew4ISi6qMMspinQcTbLjEsno1wnj9rPYko9m1giXPsgJuoIo4Ok7uIIihDC6Kye9EwQy6tZOhnl OyHU9o560tUolhh3nBAUIdRmVM9dHEGRPT0dXqJboVley30Po0KneVrfEUp6r4gluh0nBEXztBqF chdHMLegobqPq8l0nVDlZVcXs3IxKsLaBNNjlNcwYiJi6Y7w0UOproePfO2DmGhYvIwJvUSNSp1W xVnfMr2vynKy4vNe+yAmSgV1PB7PGkZMdAoq1k2uK9io3AmSG5vqPRgxUR43qtUebCC9RGPsIEs7 KEJdezbpzw6MWNeHjeqzBxsopU4yRpnZgxETwVCTnuzAiIk4vMlvj+/L1wF/paTb8B8mWsOwktBZ JZ4oFmdQnmjKbyiHV7pHSvnTNffaXe6JftWOKWHqvXYtI+Ql/U5cY5hsNCAPG+doQF53vnzhWnLR JDrbi1KyI51cl7jdbx8xEzsHGWBKH4tHndPHOgWvCgb8zbo9lWO3MR/wOLqtw4BLfWRgQN/EzuNr s4+up2p7lfB7z+GeDtMX6YbfJfzQHJS90i/o1spG8flJA7pUV1uUse2Lsmxo4xV/kQuHLw1l3akx kb+I5YQMvMXqFzxtLnrF4TS2hoLjbWzijY4DfGTNo/6ujPXM25w1K9qqat60ddfMajvj1Gtbr7nZ gsMzcOxaZtfQttyvwa/FcVs9pbQueNGW//jEuUlNb29aQ518p5oATq1hUHg9iSXGHScERUy9mVvD QK9Yscy4dNIpdCLr9dQaBnrEiiXCtQ9iIr1ejdKMJBS9Zplw6YSgKDKAU78YaG1smG7poVPsVNrl uVkMho6jWWLccULQtulcmruiYOLWW2ZcOiEo1QPg1EQGi626WGZcOumUWjUBiPk9Evqtt0S49kHM tRRwAYt4JMxbb5lw6YRgajngPNb4wOjwBSWWGZdOOuUmKQTaiZFesWKJcccJQWkgnRs7LGShADbL jEsnBKWxdHZsvJCFItgsMy6ddFZdbwngREgPUbFIuOODmDSczuA1MxDSs1EsEy6dEBTNdPpGM5mR 4tcsMy6ddNZ9e6rvCC09/cQS444Tgl3Xqu4ILb24xDLj0kln03ezeRZaOmE2xLZ2QEwEE+7aWWXp vSGWCZdOCIpm2jSrbKR3jFhmXDphUyaaaeMstJQx1RDdjgeC0iLbMLbQSOK23jLj0glBaZwncYiG dtos0933wIZTtNL6SV+j8VtviW3tg5hIpXWzvkaLBSyWCZdOCIpUWjvra3R0FM0y49IJm2qRSgDN tGlH2/03+9XOm8luQ3v/iil3izX0GknTBrhAkDZugiBVsMANYOeFXOzfD0lRJEfSyGnSbWHCn454 RqLEI1IsMW6cbGsAYMCybGA8ab9imfHRCUGVyuhnfcX7ay0zPjph56BaCeBMeB3WEuGzj+2PAHOz vpaCGqOWCR+dEFSphEJ70leSwW6Y7tHDX8XoJICTuJbaqLolxo0TgqqTUPhP4lou2qxYZnx0wu5N tRI6h3HHuLT2R1TPsxFTkQx5VtZKtbVaJnx0QlBFEsBJWSsV12qZ8dEJW1PVSWiLJmWtVF2rJcaN kzS7DUyzuFYqh9Uy46MTgiqVkzJUqoXVMt3aIzjHfRkhEZuxgY4KYbVAt3VCUNvRELDlHBnPw1pm fHRCUJUSGs9JXiuVwmqZ8dEJFm+UEsA5iFQKqyXGjROCqpTBzfJaEx2IWGZ8dEJQldKjGQiptlbL hE8+wQUjlIC5mZBORCwRbpwQVKX0dZbXSqW1WmZ8dEJQxdKXUV63eHDR6CKAk5hWKszV0nI2Tgiq Lvo8i2nNdJximfHRKbhk5NGfs5hSzaaWCJ99EFN1hNFBUrc4giqEMDqrJ7UJank1j07BnUYIfVyo Jz2Naolx44SgCqEPo3pucQRV9vx0eJVeBbG8lrVHcNlonvcLoaR+RS3RbZwQVM3zbhTKLY7gJUFD dR9Xc9FzQpl3pb6YJ5fgCqxNMT9G+RlGTEWsLoSPGqW+Hj7yZx/EVMPK63ihH9HgqtGqMuvbRf1V W87l+LyffRBTpYI8Ho/nGUZMdQoyNk2uT3BwlxGkNBbVOxgxVZ40qtUODnC9VGPiIEsbFCFTnk36 s4ERM3XYqD47OEAqGckYZWYHI6aC4SY92cCIqTh86O8T+8v3AX9vlw6KhB+HgTCR0NdV/k5pviA8 JbTfkA3v9Iy07KdX7t287ZV+9YKp4s17NxUjXEv6XTnF8K7RgPY1KdGANndnm5HkbtFH/BVfndMN +ZrMvTW/z4IX0TjoAFOepXn0b56lf4JXBQPnbd0nZaPZ2JnxNMzWYSBVGxkY8LfYndhs2uielGzv Gv7z5HBPZ3k25YbfLfxQG7S90i8o1tpGsfukAd+SSxYVosxoy4Yq3vGMq3GcrZ7sOw2h8IzSTihA K9Zn8GevJlcczhB7KDjeIVbe6DjARyYe/Xdn7Gcu3+y3QlbV742su98s2RlfPdl6v5sSHP4Cx05u dg+t3P0e/J4c9+x5f/njC1KkA6okUnHAY+7zMTGD+LfjhoFEBJnDAh4tGXLbNqf+ncVxwhUUn3cz wE5rltukpiDRvF4umU/Ia1b0Xjbl6guVl9d8YmLJIhVtoTLQF7pkuU0aFxpEjnL7RpejyglWnTkQ Lcx53WuO3kx0zeu/ZbNrFjNpWCZWw9UeWWZJk4PP/IjIwZ9cBNkjG1n0+vHB9wE5+DWLmTQs1Nz5 Fovg+EpXThBXbTyDu4dmyQH9WN9t22z/3Te7YrlPui8TtCFh54GWeg9fYTOpp3aklpeeYpg/YPBO IqEQFeyy0K6IdPIdCK2jA2nqPNlh3Zgp2See2/QRoqISj0KoEi4J7ZLKzh8xqttR/oSLuga0Sy47 f8Sow8Tqq3OVcB3NLrns/Dvmqfx9NUwVg4V2wWRnjwi1FvgKSdEeqXOIyzXd548Y1pV4uRc935LL zh8xrMfpikoN76l69w9cdv4dc/hWAZaVKmFbi3ZBdZs+QoVWHA1Vvo5ml1R2/oglWnEwXQqd4bU+ w/v8EcPsdFgCNS7M4SWHnXfHPobfJBmfTfn1fyFxh2uPtWIZE4Q0pUvKTwn6KUE/JeinBP1/JGin PNhR4LraH/cUrUDzXGRzxwi/W5PSe0oY4Nq9l8i+d53cl+bQ+9LefIXWJEpvm0NrEv1VuTqLrSf0 V+YWI7Z2zF+nzMhtRoL72wba7959xVb0+Zq4ql4MuNHF3TlDa/H0qwHTxK5rWjnW67e9STicxIcD 1uPjexehEXTpFmPXulU5BKcdWDslx92qVOEyozeXTCFVdP+GNKd9FdK+9nVKf9t3Ek64NmavIRSe wdEIocqM2mZcXIpzREPs0eCYh1h5r4uBVs4bF67vO2nkvfWv8t3QdfHt0ZX3j8jeZOV993xHNT79 FpsI1nuIe8DkEHqu3JLpnVXG4ftVL1JT+H9IOjdm3XAjFndmvFQl35NuyLiYh3vLF1kzjpNBMy6G IeNSGvKHB7ycVMtak3LDgHzWizbwgB5EHnJyTMl0lwrJwL41PiibkuddkDx3uhI9x1dMwtsTzKRk SkNOhiEDw5CAzUHuT6eUG9Y/ajLQ36+tZKAmHGegJhxfW024e77133id7cWXdJsGevKIiwxoQqZ7 lsuAZmQMQ0a6UUvykJAx3xNyUKt2vU02piEZW4KYZGwpdE8yysbfvb1c8OB7T1U6/0s6kx0UNemE 1QPH24fW8d/wu/F4++sLLaAcbz9e/vzlT199eq1f/vHbv79+g+v45fjlX7/97Z8fX7/BLvKX73// z/H77wx9//qXtz+8/PI2vrwRry3tIMGOTo8H3IvilK7X6jr28ZIAbpcvt3DqhGkgUXx+VZ9SUJuR pLYIQU7SucpACaSr81fuFM+CNlDDtxwsI5lvxau0W9apdCC1m5y8bzekxHb5E1wRSnQYIL1NcFNd sjNkfZ1jXPC0Z9oBln3tj9befTwKv4nTRFJqe2+sy5WHAXo8Wo+QqNsQe/uYw3t9/xhvQT9GqWS5 799yLTW4szl+HMOd+jC/+UQl6tOAbHY8uc+vzXD17ot4n2vO4ZtnbL1lwkSGy4/+rlqY+rIOD71q s5xPGzeEaV8MB+qGRtZ6WMusGzeEq94VOJoys3pqYMUy68YtwgPWUoHhmZKCKZYon30QO03AHY6P lLQ8Nsy38UG4arThCpx5pqTjEcusG7fkXHtYGK5oJ9ZyWItZtXdDODsL+/mQoj+sZdaNG8KXBjxB /s6k52Etkz57JahLogY9ZdSbifQ6rCXSrRvC2QT9RNEaWVM8rGXWjVtygdW4w2EOwEnxFEusWzeE kwl6wgpuYqWAimXWjRvCxUQd+4iJlAIqlkmfvZLjgkXQeaGZwimWOHdeiEbzRSryRtJC0RTLpBs3 hI3eJn/XW2alaIpl1o0bPhRGb5NfyXQhKRVLrFs3eX4YdiuZrqR7Ypl144aw0dt4vc4BoINnw4zP LsmdVm2hMKnzQVGFpJZIt24IG82NWFSPrIWqL7XMunFD2GhuLAupptvUDVNufJLLVnBjXuh08emw lli3bggbwQV41ukSaONimXXjhrBR3HjOOl3CeVjLpM9eyRUruDEtdLpETHu1RLp1Q9gIbowLnS6J Dkkss27ckqtWcAGedbok2rpYYt26IWwEF1rGWafLSXsXy6wbN4SN4kY/6zTC1jLps1dyV2tnBXUL UqrRxRLp1g1h02lEh13syFpQodQy68YNYSO54VooNYlpN0y58UneWb0FeJbpUhtdt8i6d0PY6G2o C5kuF21cLLNu3BA2mhvKLNO4xPbHdM/ztaFsaF5odKVaXy2Rbt0QNmIL8KzRlWp9tcy6cUPY6G0A uZlOqVK5r5ZZN27JB6u3IS26k0rluVpi3bohbPQW4FmmK5Xnapl144awEdwQZ5muVJ2rZdJnr+Sj 1dsQFjJdqTpXS6RbN4SN3ga/kOlK5blaZt24JfjP6C3As0xXKs/VEuvWDWGjt8EtZLomOiWxzLpx Q9gIrr9mma5U86tl0mev5E+rt4DOMl2p5FdLpFs3hI3e+rqQ6Uo1v1pm3bghXDXoHnRnOKtPZiQP hZDGF35d87FQ26CWlrV1Q/jMFl6Q0imLZdJnL0SNxMK25vhR3aiWOZ+9EoTDKCyMj8L8yQyEjZjC +EKDqZVRS6vauiFsxBTSdaHB9PCqZdaNW4LLY8QU9GrU4E9mIGx0c6G1ld4ZsbSmZx/EjGTCCxLm RKPeSi1TbtwSZJ7RTO8mqf1kBsJGHq+VqF70SFGeXvxS7ZwS6JbRxmtS1P0ERI0I1pV0UnPX19Wu w9YLUaOBZRTOLZ5A3Y3WlYVCXtQXtmVd3B1uvRA1SpcnfdxPQNTo3DkL4XZCgrfVCFqaZHA/AVEj XWnUuy2O4GUKfNjl7P08IUGtEcxzPlXq+wmI2npwUrD9BESt6ExStZ+QoPoykuNmTdpOQNTIy4cO ZFh0Pv7LfhXzWHLb4H5/xZS3xS00EqWRWiMGgrTexghSBQckwVs7CWL474ekSIozmqdNl+ZwOGKf SH4jUeQn8nG1eHB2bvSPM1KVmfr/D06S/jVuYB9MNj3psuDhgwJiUfm39hKFBpMHd1fdAA35d8RM 7b9LX9i1LumXm8OAAd1gyh8MhyUenp0Wsg/o4yW1w89dbqEUqjHnMhYEtGRiKvfVkjuG7QsX+md1 27gQTwcr/Ci6k+OCnFRiU/i+XPAKaLAkvHhdbKDxL9Si+usb91n7OIgLjfeVghyWX1FaiHJY6BeQ oNeebStlM+gbT6W/KCXzr6NXmx00tc4cJfcbgWAGPTQQO7FZ8EAjoeEFuFxAFjKbFvQSDWMsRKNP +WwwWih+n5ZKepKeaXpKS0SNg2aqBspSWSOpua6htmLQy7ByORdUr7Y3erz7f6y5S7bmdKaj1BRS 1WHqfUogIhiSUZdupHbBzJF2N6HWzUtBXbiR2jWXeIPzVFt2egeHFNSFW2rNt5w4skyQHEyTDPnc h3SOv3O4abMKb0+E4C18SO0oCBqlwwTJ12NSUBduEIKneqgkJ9Rj85JIfO1GavcAoHpuXEuikWFI QV24kdo1oYAVN4PmzUsBfe6F7Or7UihT50pAbfOSQZdupHadKeSbfrYAzXZDCurCDUL0DSvkqaVF pMzxNMmoSzdSu5YVSXPudEvmgJoU1IUbqV0rC+na6xIQB9SkgD73goAME7x23mjhcJpkzJUXaZP7 YpwaQQTi4XZIAV24kdrxLexTf0hIHE2TgrpwgwCeb1F9Q9M8nA7JqEs3Uju+xffthqZ5FhxSUBdu pHZ8i6/kHAC+eBGC+NyF2inHtqlSGzEh8rFNMujSjdSOc1F97cTx9eWpakhBXbhdukXsCGaq5mxS IZALHwjFEy62FTNPHzv36iYZdelGake4qJ55+oh8cJOCunAjtWNc7Hjmrca8eSmgz72oeXaEi13T zNNHorIfkkGXbqR2hJvSDU8fwJdkUlAXbtTXO8JF9czTB/DRTTLq0s3PKKSONzx9ZD67SUFduJHa MW7aZ54mtZcC+tyLxpg9em24AW2blwy6dPNDG6mRcOa7OoihhhTUhRupHeXGdsPUTKYqBHLhA3vw fIvqmaaP2uFUEurajdSOb3EImGn6aHxwk4K6cCO149x4zDRNW+z/Be65PY2rjmxjueHoyr3+kAy6 dCO1I1tUzxxdudcfUlAXbqR2fBt5mJpQy+aloC7cYI+eb3Eym6eTyu35kIy6dCO141tUzzRduT0f UlAXbqR2hBvTTNOVu/MhBfS5F+zJ822MNzRduTsfkkGXbqR2fBv3G5qu3J4PKagLN8C/HN+ieqbp yu35kIy6dCO149sYbmi6At+SSUFduJHaEe7eZpqu3PMPKaDPvWDPnm9RO9N05ZZ/SAZdupHa8e1e b2i6cs8/pKAu3EhdR9B35J3LXX1iATs2QiO++KvN18Jjw5C8raUbqXPx6htQvmWTAvrci7SOYvFY c/y4bxxSMJ97AYbDMSyuX4n5EwtSOzLF9RsO5lFmSN7V0o3UjkyxXG84mB/eIQV14QaYPI5Mka+u HPyJBakdb95wbeV3xiTv6bkP6Rxl4gsS50Lj2WpIgVy4AVae48w9TFT7iQWpHT22O1Jt/EhxnTZ5 qVZOgLzluLFNjLo2IK0jwXpHnTzc6b56Oiy9SOs48LgS51IPyO6O644bhmw8F/ZtNZkOl16kdUxX Jn5cG5DW8VyeiXBpAPi2OkKDiQbXBqR11AVXvlvqSdlcg4+nnL2fGwD2GtE951OnvjYgre8HJwZb G5DWk85EVWsDwO7LUU6YOWlpQFpHLx9joeCmy/a4Wjx6dmJ5/b45Xab2/4NzpH+M+9cHc03PuSxw +J6AWFT+ra1Eobnkwc1VN0BD/h0xUfvv0hd2LUv65cYwYEA3l/IHw2F5h0enhezj+XhJ7fBjl1so hUrMuYwFAS2ZiMp9teSOYfvChf5Z3TYuxNPBCr+J7uS4ICeV2BS+Lhe8AhosCS/eFhto/At1qP72 xnXWPg3iQuN9pSCH5UeUFqIcFvoFJOilZ9tK2Qz6xlPpD0rJ/OvoxWYHTa0TR8n9RiCYQQ8NxM5r FjzQSGh4AS4XkIXLpgW9RMMYC9HYUz4bjBWK36elkp6kZ5qe0hJR46CZqoGyVNZIaq5rqK0Y9DKs XM4F9Xj5CWstIBh2ZP0FADkDO/Ry7ZvKeuFZ0h0kdGjR6wf6sYUTLjCYL1KVHBr7LU73KCejzizJ 9Qg1nD4R7BOy0yDRsZ3qG+6+McFY7yE7td+203sUZ3TdaTaKwo19cJV1a6Mk7avlVsjliG7r9zAZ r+7EhbqgB34C44wuW8V8ATgFtcnLZEFt8tZYUKv0Vf7iJpjDsqjHUH9bUO9QTkaXnaYotK7RSEky 24ojSbVpUHHhFJ57mGgHBq2xeMqiJzDO6LzV8JaBBh6SPPKk1uQF4UJP3Evyq40OVyW+pcSjBnXQ kEfyFmpYXzTSU7yN/q8EeqwL1/6MdLKfdNyoUsAMDGhbJO/BvMOkpHaD+MrAeD4heQ/m7Ccdtz50 3wp2xLZ1eQ/mHS7KvbeQbw6sNzj1PmYn+0nHIwy9JTYRJB5P0v3Ozg6Tknq0QO/OPG7eo3mHSRlJ d4xztp2ngv0ZmLO/6ALPVXh7Awvy1uUd1sl+0h38IXBDS2lbl/dg3mFSUlPOnaWh8XW2J9d5dpiU kQO6a9Cotu9RvOFF+XFdYDb53Ohv/xtQ2EJ/1ocS6FDMOEo43xnqO0N9Z6jvDPV/YagVMdFoQr1U /y/DSZ81m7aVOo02mXdsXG3SrtpA22Qa1ZH3CDKN7jrGBeIAWogyiQRiGFrYZY87xQgXQpNOfO9z Xahm0LvZcMiMtMtoGHSS23vPmNohnfnNgnxkuOwX0NM3acg5bWraNl5w9QcbsUgWHImWBKc0nUNG +EI9BbjKyewK6hjk+iXVt9MIagY6pBqETrH2EZ1zbRspm0XfaCp9NLCjJJwVoj9satL9azggmEUP GESZUTmeoGmg4c67XfK00AcB5yILhigns29qYtiuJHNs2/oRPZhtW49u6anBsQR24WvnAGu07Aq0 TM6F9BCuCfSo1cbEin9fKi7US8VdEqK9XTNGhtKRU/VSb31Oc/UGl+qSxB/llcqlvKBeakUWwK7m Wl3n3xpmc7CFEfcCp4/awqjAfKaFm4LLJ66xYGlsqmSQRU+Kx5VbP7ortwiX8uoLrrzSOT8E06pL P+qq65SDtm1XS/1grpb60S3zNTgwblkWwOLZA2zlNC1IbZiH/h7lBpcC1oVRbum88Zvygkt19WR0 1FMvxQXn8EqwXG31gjiXDNfWD+8vWJt137kflz8TPoMVQtn2nGi77x+jX//zl59fMTfql19/+/fr V3wuv2w//uu3v//z4/VrTPjr2y//2f74TVTfXv/y/qcXNC9tP7av9W0PKW3vf0C497+S+P3ly/b6 /o+XH99f/jsAtsfTZQplbmRzdHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v UGFyZW50IDE3IDAgUiANL1Jlc291cmNlcyA4IDAgUiANL0NvbnRlbnRzIDkgMCBSIA0vTWVkaWFC b3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCAN Pj4gDWVuZG9iag04IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwg L1RUNCAyNiAwIFIgL1RUNiAyNyAwIFIgL1RUOCAxMyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dT MSAzMSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMjggMCBSID4+IA0+PiANZW5kb2JqDTkg MCBvYmoNPDwgL0xlbmd0aCAxNDk4OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI iexX32/bOBJ+11/BRylYq6QoUdTjJm33WnQXBeLbfSj64CRy4j3HDhxlg/vvb2b4w5ST9NygrYmU MCCLI3Lm48x8w+HxNHs1nWom2HSedWWnGIcfvShZ8por1tYtm15nr05uG3Z+S985uz3PXv12Ktjl bcZLzkXDpuf+7T77lL89efexmOhS5ezdqmjLJh/6zbqY1PB2Y/5YIap8WkxEXVZ5X0x4Wee3A7PL lkUF4plZy4pJJ3UD4n//8a/xjDuacGlUzosu0FVMVNnlA01j783ITF+CvlLn/y1EhwiFWa3M34SU VGbAzd8vABNxjKWclAm3nYloOvBaB6+fp+8zziatKIWswCWvYYQeQufA5+nf6Pbau10L4RyPr6JS 1veCl61C9/tF6rFY+QWqk6WkBRiMqkWjE3yVtYnLyXo1X1zebQpVynxW1LD9Afem8sV6BdtDQVlI cJ+w7+RrSQOzr72Qq7Yp2wqBkPlK7yYIAFmBYVG2eX9eTFoIx7DAsIj8nwVAqhrwKQQIcbKZnTnY MHwAQSVBYCf0BYfnBkNcUyCqXJq/+8VwZRezt8WkAfUnsBaz0lqzOhfextrpcZLVBcM0bWHyLDR0 2Q/Mvq7t1Lsx0MXq0hl3GuyC2XwOAolzCplbB7Dhyum7u7xi17TJ2hp13nI++WDHkr6yW6PiHje3 GKzCq96KfUbCilpKSkgMhs2K034wyFV+w6zDVN4TQ/+C9K7Bzq+A8w92Y7wj84E0w8Zm4B4wB0xq c0gu2lWdU47RxJ4NVnbVm5j8/it4Pj/5hb2zHz4WGOOVNXthZn3ESesCmexMolMhLjd2vL5xQK0A aF0J46B6tOWmoS2b9H+I0KqBnfvXh/tc208rgjTyEsJ9A4thidDwcQWJcWtdco+gOxeS1oWktRFr 7Ra3TqJhT6FXfi8za8z7dLEyZi8Wbj/uvw9d1q8GZ+fuzDm493syPpoegWeO75AP4EIJSXrB3FbW d4MHTAadX5xaY264c7FgF2PoKwfdZLPEfAcL1hvbWA5rK1ovH3fQemU9vQ0N+491somJi9B9AWVT 5E7NlZezYW1UIHPpBQRBdrqJNtF8NrgtO2+Zilr5ktbZknaFlUzD4QG4Ko6nDlY5JzTlrYHyZv6N 4Q4d1dChgYBeEa8rgL+Acwuyzav6sLi8wsChKhuKFeUFTl7S5KVRzH5DvNpquJxQKLv8jaFYRfGl WthQLfQlc+E+D4ZQ2uZUl8/sFnpnf+wK0TpXcFtQ/uw3mJhVDcphf63L8IoyXNgMr0ya0FdIG4ga JCd9HdBpyhRSin5vP8/os/1oNLH1VnOoY1Oyj7NbM9P+URWmeDZ4/FENxoULON6E08rm0KhQSlwT RkmHxUAHBGof1vZlg/lkNBpYG8or9MybKVQeXja8Ms2SYAuWwbkIh7NgUrelYrLCox0CBsfkps/m psM6OYVlSkl46g77stMTWPweXv5GUc3umeDsd/bpM2cXW42tRjVSlJppOIBR4fFRVks44Cpn8Dqr aw0qYNxBEDVbbgW6K2scuwVG33JHwzKbfw+lZ/sohWLCdSgYOfOZSL9WKSD1/W8NHYrmuLhCj4N6 yPYOF3ccezBcXZVa7wj4Y57pRGkcA5yksaQR9FzaG1juWjR7jAOFhBJFnoWSrwkF6KZJuJrUtKWs RgJvBdMa0wbKAS2BPn+MCwqEEehSKG9luWs2Oihw3tEkrctG2dhwHobCJ2Ag6MJYQKEhZ7tY4WVJ Bwnqx2RiuWszMhxQXpVJLAQB/UUdhgEvYzoUVMKw0YfBWfGBgrNDj5JTYI3xuRsYjAQBXJHgR+XD fXmauNKWqwfEdU72aelnuEz2ZB1Z2XHCD7fsSULu3I+byCfvzhpuTKN4PCSmE/gZI5tx4fAksQeU C4RnmaWlH7tk25OVI/2HM9naajomnWMQtLfj6vsF0o0I9gTjttZiMD9qA/9PB5jauR/ezqWIxBaR 1GCnBjs12KnBTg12arBTg50a7D0a7NQvpH4h9QupX3gegij4GgeKiKgaEZRo2BoLjsNz9tAI0i0j hu4+FhzplrF86beMxPPE88Tzl89zzkA/rxinw50ro5u8A6RqFZt0sJxt+my+/dyiSiZFqZlGK/D1 +GibUy52tbY01QCQ0tIKdjt4o2+5o8Fy4VsrPdtHqW8snWDkmWci/VqliDRFJLKIAGEsWeK4wsaB IqLba0RQornAxoLj0NfYwyMQDH9UPlKDnRrs1GD/BA126hdSv5D6hdQvPA9BFHyNA0VEVI0ISjRs jQXH4Tl7aATplhFDdx8LjnTLWL70W0bieeJ54vnL5zlnoJ9XjNPhzpXRTd4BUrWKTTpYzjZ9Nt9+ blElk6LUTKMV+Hp8tM0pF7taW5pqAEhpaQW7HbzRt9zRYLnwrZWe7aPUN5ZOMPLMM5F+rVJEmiIS WUSAMJYscVxh40AR0e01IijRXGBjwXHoa2wMCKLgaxwoIqJqRFCiYWssOA7P2UMjEAx/1HSMrq2P ElfaJucBcZ2TfVr6GS6TPVlHVnac8MMtj6+m+3ET+eTdWUuw/2ViOoGfMbIZF47RHTYIhGeZpaUf u2Tbk5Uj/Yczub2phqRzDKr4TvX9AulGBHuCcVtrcZhPPE88Tzx/6TznDH90sEfRkceBIqJmPCIo 0fTjseA4dFceA4Io+BoHioioGhGUaNgaC47Dc/bQCATDHzUd6ZaRbhnplvHSbxmJ54nniecvn+ec 4Q8OdvNyekJdJLGrVphb14Ggg6RjmGqUKY3AlhERV9wPzwkxudh+F9I0J3a1H5J2mO4FNQL2q2sB /NxqN8PzzFu33z02s3qM/Tw7O8pCixUDJgnFhACnsk2fHR9tt9eAqXC7iqPHvUElt2jgPdgofnFG 7CI3JJ3BJpsGC9TWRRJCF7iQhsEm7XeP0KweAR7vsXGtst90a9MgWGRmeFfZGacZh4SSzD2bqqK8 KGuFQ/OU4PNRjrS2Rgc5ghCfnyO4egx+nCMqzBG47wQpgqMwQ+hrkCAqTBCr+qHzTIZMfIrMwQW6 aZh/wjpshEET8QpWeZqQQAkoUWHeQKUNUweHo+yh78KWbLvaDY124wIjUCZlnAOB/HXgYBqGGWS+ e7DKJVSA/Zzq0JMJ8mA/e/HAbyNwbUgEhV4OtxE6yQzH28DvHqNZPYb8LZmQqmKqijYXUuR/1sin 8zCdh+k8fJIJKelT0kea9CksUYYl9eapQ0sdWjqsUlVMVTFVxe9WFVPkf9bIp/MwnYfpPHySCSnp U9JHmvQpLFGG5RvVolbUzD2VoFpUcQmcFKzmFYIRDT4nUiMUS9+qw/n2WbV4bLtVUtWltotgDUTB tEJgRJMp8xRjSxK9eA2CplQkaCBwALECx2EEtwKhy67yS5a7OpYY4++i9wz3ILVm7ll1Zt9YB2Hf XYNebaFtasrab7qDWf7JlVlhwMiuLQmc4LDSjU1Y6hYtmKdsWnKWRWgcfO23IFVb1vV+exqpIFc9 HkuYx7XhbKf2toVLbNIsd3VY/z3qDpc40FeTOxxIHG8DIXWLmoMJRmAc9sWMJNChZreLQHWndlQT 6NOnMLug0yo7qjm3eiGiWgeCxLTEtMS0H8O042kG/oATj8PPvMHRC9ZBoWxrbEKn1xmnz3QH5VxK NoU3Nr3PPuWnfaFLmW/gqfJ/Cmhb29yJPk/fZ7ItVQXdhCiFgIBMX5MK0ZAKVNYaPW9PYFGbs9P7 ooKjOV8MxUSC4LyYNPkVqcL2H+oBiLVADK+zCWpoRAinmOiyzmExbFXm683ssqfFb6Z2E+Aljs3P PQN3CPAmuEMKrAfXWwE04do4TFIn8lDg8qvGDaJLJfkK+gbZGKcbwdILZNdR3mA7Q63HgzFVJSOg pq5VEF1U6QWNXdHBzEfG0GpRauBNicqZlv9jv2p6I8lt6L1/RR3tQxdUJdXX1ckiQK7rW5CLF3Z2 F70XJ8D+/VAiKYkqI3EDNSiOhzDGnlaryFek3tNj0jMf+x01A7QA1r2P2K8bq+Y8x9lq3aBLWJ4V y7NtKW1YI//xoY0FhPgPiVwSZ++jF8sp/rjEiSee4cktvY8oeSGAnMyxlvmRdcbiNjGSDnyTuC/4 AgtAHyT4OUnYPsfgkuPMC7k26YlbE6FBflRQhI1E9CMwbY4Pj3iV+GFLZ3eCXqdj5OHUrEEsLMh+ OGgB409JCssOIEJYc9BbmwXf68TMcxoEJjcj1/wY0rmeQOgSGz2c0nEVCyXuhgtblBFYmKLPr6Fw W6jqlOXWplUHZVhRkvD8l34EOE5J5fmgVQtDuk4mN+BN5QHkGuoGOfhPqEkls5ydeRyTVaFaxvL7 RJ0p3pwpzBCSqlYLMxS1rrbbqEHcj2FMp7ScwcEnM1F2yLTaoAzdQHqWyTOgNfFgi1B7jqSod+li K72UaRu1UACFyZPK/jnOjr0XZc+czTsYG1M0L3BzZVp1UICzeMnsSMzlB8460Y98OrkfexLjgc43 Wf6cSS2yakNSkQuvuD2nJyr+HZxmCvMZrThNd55Iqw3KfbbS3KNK92gd/N47aP5fg+lWBMX8v/l/ 8//m/83/m///xv7fvIeGC18RFPMe5j1OZ6ZpgioopgmmCTaP2Dxi88hhSPQMAaqgKKKyIih6qKwI ih4u60GiicpqoLjO9dMa4Pfq0bxA1dOhBTrCuo8xuusaUby/Xt4uI3jJBBUgQ178nr9+woB+WmJY N6aA7KIxILxsCCgWwZPP5gUIhu3jRwDwJpw4xsAifou4L/gCC0AfJHg4kx/mIIudF3J90hO3JkKD /KigCBt+avfp12ZA9HMjzmUBxXmCsFKc8w4WZwx6a7PIa+GEzKSBYWzmweAa6S0LJa6U3jA082Bu C1cds9zatOqg0OhG57/uxyQHxGqBBkS/yAGxNIgGxEIqmeXszKxxWMtKWqGmch4sCyStudosrbkf fCPlM8jSmnfItNqg7EdTrHLl3A6lKDu33EuZtlELBVCYPEPj3P4HZ8m57TnrGueWKZoXhsa58YIy KGSiPiBxkNatWuDTOUvrVpGYD/TYy89eWjcpJ2qQVOSSzq1QmJzbPZxmCi+Ncyt3nkirDYqZyK9j Iq2RX6SRNg1osOCKoNg0YNOATQM2Ddg0YNPAN54GzHtouPAVQTHvYd7jdGaaJqiCYppgmmDziM0j No8chkTPEKAKiiIqK4Kih8qKoOjhsh4kmqisBorrXD+tAX6vHs2Lc+nQ+nXp587HEN11jSDeXy9v l3HbElK/bOCq6Hv++gnj+WmJUd2Y4pGJxnjwqiEkqfDbRjB5Yd361Dt+YFmZAnUELODhQV8Q+gKg Bwl7JTLvUpC5zgu5NPjIrY3RID8wLoKHn8p8+s0DaSrC+W3sXai0uVpAbfZbzFxpTNlB2kxBb20W cSuckRkl0G9rVIyivH6b+bZB5a0WOG6cDirl9dsCkiygcGO47Jjl1qZVB4UmN+RA3Y6hlweNP+Nw GGu/1rpbukPDYWaVyHBiUhI2qmDRU79NfCHgEFgtoJ6WGpOeli7QNVROHulp2SHTaoOym0epxsWu HUtMsmulkzJtoxEKoDBlUtk/x1S0ax8wdZauthAzL3BzZVp1UMg57fnL1Se7Vi3w4eR27BlM5zlf YHmBKV0n1YUjE4svtT2fJyr8HXxm+vL5zAv5lhNptUEx1/hlXKP18Wv00dy/BsutCIq5f3P/5v7N /Zv7N/d/uPs3t6HhilcExdzGD+02TAlMCUwJTAls7vi/UPSYfUVQtPh9LTj0mH1VUBTRWBEUPTRW BEULk7Xg0ERjNVBc5/oJPgB3PZoW59KBDQBp7nwM0V3XGPH99fJ2GcEKR6QBAEJa/J6/fsJ4flpi VDemeGSZMR68aghJJgKcYewlL4wTto4fAL+21KYbI2ABDw/6gtAXAD1I2CGesI9SkKPOC7k0+Mit jdEgPzAugoefynSGcZPTYAA5FrpcLaAuh6gitS6XHaTLFPTWZhE3whmZUf4CFCZUohtAWoXoVgsU Nt4vtegG2BkEktwXrnpKcmuS6sJBoxqe/roRixgGy2ccBmPVxTBY+kLDYOaTyHBiUpI0ql9R0gCF FWNftYBKWipMSlp6QPdPOXOkpGWHTKsNym4CpRoXk3YsJcmklU7KtI06KIDCjEll/xxP0aR9wNNR mrRMy/yZeyuzakNChmnP3lm6tGqBj+YqXVrFXzrN+eLKC5NwaUJFlOBgWuXLbM/miep+B5uJvPl0 5oVNWjR5u6mBYm7xy7hF6+PX6KO5/tPdthYc5vrN9ZvrN9dvrt9c/8Gu31zG6be7FhzmMn5ol2Ea YBpgGvBja4BNGjZp3ItEi8PXgkOPvVcFRRGJFUFRw2I9SLTwWAsOTSRWA8V1rp/gAzDXo2FxLp1X P0Uidj7G6K4p5Pvr5e0ybluC6kOETN/z108Y0E9LDOvGFJDcMgWElw0hyYSffQTFn6ZIi664ax8A bf0Zn8cCHh3zBYEvAHmQoEeisUxATho/5ZLg5lv7dAP5kIgIGH4qjwllj80oFPPTBAa/EuJqAYXY TzFuJSllBwkxBb21WcQVcEZmVDw/jzCRVDrrZzh/c6Wz1QLHXUk0SGeBV71Agh3hkmOGW5tSFQya y+jAyz64tT5fZQGHPz/NUNxKZEtjaPgrLJJZzs5MakZ1LCLqp1jP9BROe9UCimiuNGloaQXdPOXo kYaWHTKrMiS7sZNqXLzZscQkb1Y6KdM2GqEAClMnVv1zZEVv9gFZ8w5mK/MzL1BrRVJdOMglfUBe Ljx5s2qBzyV3Yk9ePsqjdCoVm0VadVAysfhS29MZ3dk9dGb28vHMC/mSE1mVITGb+D3bRGvdd9s6 c/hnW2slMMzhm8M3h28O/04cimy1IihqfLUeJOY1FFzySmCY1zCvcTIfTQlUwDAlMCWwqcOmjjtx KLL6iqCo8fqakCgisSIoSnisBYciEiuCoojFWpC4zvXTGuD36tGwOJeObIDEsMnHGN0VeLx276+X t8u4bQlpmIZ+pa/52yeMB/FjVDemeGSbKR68aghJJcICL5J6xwvwZviq+RFAFcTCVkr4LeK+4Ass AH0Q4IGM8/phEjLVeSHXBx+5tTEk+CPjInj4qWxnmIFCc8W6MAeeXlCbqwXU5gA6I4Sn7CBtpqC3 Nou4Fc7IjDoYFjjBlfiGee1r7S2fOejcr5XyhnkjUWEYuSlc8pTh1mRUBIKmNDr5dQ883Db18SoL OAtCQSvBLR2hQbBwSaY4NS3JGpawaGmYFxZCHPqqBdTSUmQS09wFuoHKeSMtzRtETk0wdpNnLG3x ZseykLwZda9K2ErBaQiIG1jhz9AR7diejvw9s5HIlxFyC2VGTSjIEX3ATi43GbFqgc8f139PUD6x fCvlhcxYkVYdlMwgvq72tJ2o+J+nLbN0kp/47hIpNcEwN/jF3KB18yt107y9eXvz9ubtVTjr8xGo cNU6UCgy1Iqg6DDVSmCYfzj96lYBwvzDD+sfjPnGfGP+j8h8mxwEAhWeXQcKRXZdERQdll0NjPMZ ez4CFWzVgUIRURVB0UJWFTBc5/ppDfB79Wg8nEsnNWYPa+djjO66de+vl7fLuG0Jo3dLRIBfpu+e MJSflhjQjSkUeV0KBa8YQhIEoH2Ew5+GBd6iK97Yuznuv7UBsG6HB31B6AuAHiTsmcgrM5ALxk+5 Irj51j7dYD4kIgKGn8onpr81sdLfsRLdagFFN7nxsRKTsoNEl4Le2ixC68/IjFoX/w5zpa7xr6/l tVrguCMUtxJYP069QIId4ZJjhlubUhUMGqroxMs+uLU+X2UB57Z4QS+1tJbG0OhWaCSznJ2ZlIzq WMQz/UXlx3GtWkDxzJUm7SytoPumHD3Sz7JDZlWGZDc6Uo2LDzuWmOTDSidl2kYjFEBh6sSqf46s 6Mk+IGuQbrXwMy9Qa0VSXTjIGn1AXi48ObJqgc5l7sSevHSU892VFzKbRVp1UDKx+FLb03mi4n+e zsxePp55IV9yIqsyJGYRv1eLaG37Lttmzv5sS60Ehjl7c/bm7M3Z34lDkZ1WBEWNn9aDxLyGgkte CQzzGuY1TuajKYEKGKYEpgQ2ddjUcScORVZfERQ1Xl8TEkUkVgRFCY+14FBEYkVQFLFYC5Kn58va Owjg4Af/h+V3czduHk4vPPD8x8WlDWBorq53zsPaL5eHv/32r+tPj8+/x8Vl3LbuOvTDNizd819x 3xS3/ePh58fr2vuHPx+hGcPDb49XeJWH/zxeoyF9+AX+Dv308Ovrvx//+fz3y0/PlOznv1xi2O7P 7jJCNSJLQlgTryBXKteU2JNezaczBCVj+08LbiEa0UJYgT2h2hGWAWxxvSNszQ4gnNwBFdrGaoff NjqYvLDMzY7Z118HUMr6W5wwwkwNW+C7AMij9w6giC5m/xnKAX2if9CKAV4l+ve4A874lN5jgMDv r5fRL8mo03dQMo9aHLxH91927BYGpMyv5aEQCRijhCkVPkCydOryAsgWBtmlESHSofsv41WQLEuK w/Z9irxAV4AhSTjHXKPeeq4/yBhw4oKY6HjuXwgpAYMw7lMc1Vnkkq/27zqbRfrvn7qT+DoZ38J8 W4JEajbg0kBDyXxqYpQzQHjipNaQQKF6fODIs8cYn2iYAZs58wzi1f8w9jFrNii1Tkak/j+9FyrX ES4NnvpnnlguHV8fezCn98dCWj5Gi/R7jk2iPVneu+lPNUgqx3KbhpGQNWX/x35ZNt0yjM22V1+9 AxL5b33YRWx8oDFqtB6egfKaJofEzSiaexZQnpagbDqrZr50FM09y+fUJi6o/6RV0uOMzMiSBxLA tvkbWM9XNpK8iiOK5J4FNGeNejNMHp8EEdxTfK738VzoarXRpIc4MSOy5okFNM4vRuxto/lcOorm ngVUuUDkM7lo1ltQR9Hcs3zOXKh1tH7fSN6Xjix5IAFUNlPvj2RSHsqlo0juWUDL3BD1vBaT8hgu HUVzz/K5FSsTDUbz5nUckTVPLKBJrXWEk62avJAjiuae5QuqlokGXOKrJq/kiNA8soCGpFEjmXgh RxTJLQngo9aaYOqL5MPrOKJI7llwbmWq0b9MVTR5HUdkzRMLqDLV6H9Y8cOGOaJo7lnjhhHU/bDi zPY2omjuWb6QdtV6M5mpc7YlsN6BAVA5Kq5akx4ufGYUyT0LqDJVlAjrGB8uqWYUzT3L1/JemWp4 rBXz/umBBU8UoGmuckA1awTjpaNo7llAi1ppM2vi+Y4oghuKL1Gbaa3rzYzpvnRkvQMJoPLSEK0D PwEHe0aR3LOAKi8NwTrwEzkpI4rmnuXLrb00II9Gkyc9ImueWECVlwZs4FXz5lmPKJp7li9Je2kt Ao0DP4lnPSJrnlhAlZmisDSSXF+PKJJbEkDlpcFZB34e+M+MIrln+fJoL6ViHZhtsgcWPFGAKiOl Yu33yU2sR9Hcs4AqI6Vs7fcpPOURRXPPwqNNmSk9xn4xvPbHYofu8wHYwGS9N3ONPqNI7llAlYtS st6buUifUTT3LF+KNlI8StfcZK7SZ2TNEwuoMlKK1n4zF9UziuaeBVR5qfGMzBX1jCK4oZDDxTuh gBfeIsjl9Ix47x5ZQJNaZ8I7c9W8Lx1Fc88CqqyUvDXgzAX1jKK5Z9UbRFtpRe1ickE9I2ueWECV lZKzBpwjp2ZE0dyzyJG2Ul8+JkVco8/IkgcSQOWkFXRWknMzokjuWUCVlfpsDThziT6jaO5Z5IJ2 U/+sBnzuAFQZZ0WN3WYu8WfkIZ1YQJVx+mTtNidO7YiiuWeRi9o//W3tliu+GVnyQAKo7LM2L6Z7 7gBUOaWPP/yVHx0zyoj2LHK3dkoffvgrX6QzsuaJBVQ5pafVX88dgCpf9CaRmW+PEWU8Gwq5pE3R +x9Wyi+gGVnwxAKqTNG71UrPHchh8w60ICwjKnzx8IkssQ3owAEYnQL9ut4HHKByufzDGvn51ceU +3C2JHJZm9zzWTf5HgamzOyxDlj43daGVJxk/0ACqKwMtaoZzRYnV7SRoR5fyAccoHKse7W5Iw5Q WVNc/eyIU91wyoTCYlwnGJiu8IxDnXCAupRb/emIEw6Z8pTViI44QOUozjjOCQeo3ONvNuDlEa/v 2uPLW/HCf9h+AyRk4Y+3VPsYN3zZnnJsDU2vXjzNHwgP2q+qCwgvsq+qu7iK+6ryM2CXfV+PpLpn v6/3YmyUODZY6xDqyW+/H+IGP2xKGtzowfP0+dYbXDUEXPGaMhtEtD5Yy+uzs0HGVRuaaB95oD4O mVttiK/Z1+flk/T61IaoF7D+dq8lDngOqRwENuPvzJJJ8my42yUQnGSpFkJONFuWqE/eYy+jwbdj 2YdFYXRIrSF+SDpk1qyPE2rLxb8egaklleobUOC2NFQfmmx2ffEouPd6U/0HxVeDlDk9RRSyrMXa 0NM8KLOBxulr4wjuvXfGwGS3jan0/TlmWnewTF3Wom/psVp904/lHMeiL/g4OD0l42j1pI3D9z6e 7ex+cNe3P7zE3rv8Dq96Faj26WDr1eTgKTOK5p4FVK3vTbZeTS5fOormnuVz0rZ+e1OvJo+7c0aW PJAAKrO/3XobQIZXcUSR3LOAqjvgdraITTw+CSK4p/j86HshFlvBJuLEjMiaJxbQOL8Ysy3REj2X jqK5ZwFVZ6yiprJNAS+JGUVzz/I5jzMGtH7fSN6Xjix5IAG8536IqGONZLl0FMk9C2iZGyKiVl81 I556M4rmnuVzETPpaDCaN6/jiKx5YgFVRS18zCznzQs5omjuWbgeVbFbja2YrN+8kiNC88gCqupd mOUqmXghRxTJLQmgKoIj37qLJL9yZxTJPQt1gDLV6F+mKpq8jiOy5okFVJlq9D+smN+pM4rmngVU V9LuhxXz03BG0dyzfKFXhV2sFXO2JbDegQFQOSoua5MefhDNKJJ7FlBlqhU1PvzwU2tG0dyzUOkp Uw2PtWLePz2w4IkCVJXtIa11PWS4nB9RNPcsoKqWN7bxEM93RBHcUFDLKjMNt3Hgh+5LR9Y7kAAq Lw3ROvATcLBnFMk9C6jy0hCsAz+RkzKiaO5ZKNqVlwbk0WjypEdkzRNLP2GAYgOvmjfPekTR3LPw llBeWutu48BP4lmPyJonFlBlphW1kuXSUSS3JP2aA+isAz8P/GdGkdyzfHm0l9b63Dgw22QPLHii AFVGWlFjv09uYj2K5p4FVBlpfe4Y+30KT3lE0dyzfMnaTOtDZJ03htf+WOzQHaByUUrWezPX6DOK 5J4FVLkoJeu9mYv0GUVzz/KlaCOl23pv5ip9RtY8sYAqI6Vo7TdzUT2jaO5ZQJWXGs/IXFHPKIIb Cjknr70G8btxEeRyesYqeGYBTWqdq52Y7HA9PaNo7llAlZWStwacuaCeUTT3rHqDaCutqF1MLqhn ZM0TC6iyUnLWgHPk1IwomnsWOdJW6svHpIhr9BlZ8kACqJy0gs5Kcm5GFMk9C6iyUp+tAWcu0WcU zT2LXNBu6p/VgM8dgCrjrKix28wl/ow8pBMLqDJOn6zd5sSpHVE09yxyUfunv63dcsU3I0seSACV fdbmxXTPHYAqp/Txh7/yo2NGGdGeRe7WTunDD3/li3RG1jyxgCqn9LT667kDUOWL3iQy8+0xooxn QyGXtCl6/8NK+QU0IwueWECVKXq3Wum5Azls3oEWhGVEhS8ePpEltgEdOACjU6Bf1/uAA1Qul39Y Iz+/+phyH86WRC5rk3s+6ybfw8CUmT3WAQu/29qQipPsH0gAlZWhVjWj2eLkijYy1OML+YADVI51 rzZ3xAEqa4qrnx1xqhtOmVBYjOsEA9MVnnGoEw5Ql3KrPx1xwiFTnrIa0REHqBzFGcc54QCVe/zN Brw84vVde3zbVqwVxn8vhRGS8Mc7qn2LG77sTjm2hiZX751mD4T37FeVBYQH2VeVXVzEfVX1GbDJ vq83Ut2y39dzMTZKHPurdQj14LffD3GDHy4lDW704Gn6fOv9rRoCbnhNmQ0iWt+r5fXZ2SDjqg1N tI88UB+HzK02xNfs6+vySXp9akPUC1h/u9cSB7yGVA4Ce/F3ZsnkeDbc7Q4ITrJU6yAnmi1L1Cfv sZXR4Nup7MOiMDqk1hA/JB0ya9a3CbXl4l+PwNSSSvUJKHBbGqrvTPa6vngU3Hu9qf6D4qtBqpye IgpZ1mJt6GkelNlA4/C1cQT33jtjYLLbxlT6/hwzrTtYpi5r0bf0WK2+6cdyjmPRF3wcnJ6ScbR6 0sbhex/P7z//qSfX1T1Siza+PCoesz6+noaCfAOPHjR4WdBKaUfP81TFXxYVP050W+PR0Egbkdml eVRQV7hfXaZ/QDwkS4r6MMetP79gVdJwojbM0SDD/CWiu6zDpGF1dVR/L6sTZwvy+Ks7Sn67rIb9 W6W/cYaD9oYx2d8yqtMy0rpRsntlLIl/jrwnua1G3pPUYCplRmXuP8l7b+h5/ykyuyzDfO/4P27o +1nOhJdjJAtaO7yW5qdKfSam15U0Gvpkf8m8O71HWn014iGEyE8hn6uLp3G+A+7Lf/nOr4QVBOJm lXf/j/1qadEkN4L3+RV1nDlMUyWp9LgaFozPfTHGJ7NgQ7dfeNm/b0UqlcpSfpL35sswdDKfQhGl ZygzofRDfCk1ek+Ia5UmVqZLxRPvfaQbb6WeBANSWlsfEBELGBfiazHV32BUQeDxETEqYRBfi2mC ASlZxN51teTK0eJrNU2YwItScBxgEWtJUn69aI/+BqNSB4df6gdPhYx/PbInwYDIa3HiX5Sjr9U0 wYCoDE48aVJOXFRIXCs1TZhA+sh3ugSiFu6jxVdqT4IBEw08jHUrsRwtvlbTBAMGGrgf61ZoS8ti S58EA+LqUmxquOGvVXTHCfycG8hT/nenv/42ofM424s+QLzJzXe67fzwqR8+9cOnfvjU/9GndvaE 2gR5Vfvj6qQVpRFX4lOVrbFnwr2wjb2w5Yy7NmROlalQ8Al3Cw29YkxUpF6lsGSCyaAhttKkloUh U8Pd8r7a0DqE+vH2m4q/q/Q6N7d68SoXf0MaTulB6eSV75awv2q43EThBhF9fvMxpNSqyzFmM6vU 9mLMO/bS5JSV46XsSxelVmkd7l519MW/20KM7bk52+fUXn5zvSqEnpmLZK95+zddn2YflAst35dh u7tacJvY1Xok7sEzdS5Lj9R6lJbc99Vy/lRL67xrpST/8jwi3gdHm7poaJNQFG4QxXYe1Ae5QYaU +8r0WfApHPPMj2WQOfWFasd6LGQ/97LUfDFkL/rKymb1u/W8fR9sUCeew1zIkOv/H9eUdvF5TVsZ qK7p8yjFUdH2s9bKT3Uai5vuqWtHPMsR5xM9Li7fmHFxXZhuro/TzW13XV3DqUG+MhY6PkUTEovn 3XuOy4y8bYW+iiFMkz+fLnbzeVF3cb6KPk5X0T138+Zjqy4n9xi3s2mo2/m8nH0U6naez0PKh0zd RZenq3e7x03ot1Vuk2noN0FdnvAUzX3g/cbzxuvbdM2uEeepsK8MJ2onUl2g8FwvPtTqArXVeN4L ukC/e/9S3koqifJ1/u8VQ2Wc8QiOXuX3z5HP13f6PGu6+P6XL/hftbj3X7/86esfv13hLX/9xy// /va9DvDr8dO/fvnbPz+/fa/ziF9//vt/jt//zNDP3/78/ocvP73Pr6vP9QnGDKuX1HTsvvBpvDF4 i0O1LDqjDfysDaHNzmEmA37+os5IBqR789jKrw/+iT4h0GGS35VLh2n+wIO/Np+n7medVWo7y9/x uVYo2uxHQ2hH0NcL3C6Xp0MbzsQX2redx67krDrI2FjBDHaeLA2e0jf6w7CFgp56fYxGfxI0Jeep 4RSDToEqDImPj2Hq08fC9C0XJunn77O9FlzMHL8e8zn6VA2PDXCL7Xju1284J9Nhm77/YfPI6aO3 b+Vk9W0cdaDFaZSKMEan6rRF1lyzMKbuL0AdFTyTZj505Bu5ZgGN44TU+xpnyYtKVYksuST5PJJj gDjmRpJWUSJJ7lhAVXJV0csMk8bHgQXXFKBpLHQorRJ9CtLGSGTNNctnL686UMrCZs106EiaOxZQ lYMHemkmTX8dOrLmmgU0j6UOuK2z5H3oyJJLks+hru4A6XGbJcuhI0nuWEBvtdb02k2awR86suaa BTRFjXqjedM6SmTNNcvnW1I3oAFP/6xJCymRNHcsoEGdCY/sYdaklZTImmsW0Bw0aiQjLaREllyS fI6ShwF0SJwmyUTrKJEkdyygylSrTSezQ4nWUSJrrllAlamS9RtNMkyJrLlmyQPD6PnCijPZm0TS 3LGAKlf1xVox7TYH1lsyfM7aUZHwmu2hnGdEktyxgCpTReI7jzFRNjUia65ZQJWpInmYt4fOTw8s uKb4XLSjehRKRjAcOpLmjgVUOWpFjQ8nR1OWyJprFlBlqTWfN/N296EjSy5JvpzaUWt6ZXw4eVzv ESG5ZQFVjlqzVePDKdDWSGTNNQtozhp1ZuqBJi2RNdcsX1BqDNQhi540b5q1RNLcsYBGtdg1RZ4l I01aIksuSQCVoVbQDJLu94isuCT54rSf1lTauHBK8KARSXLHAqr81BXrwmSVPbDgmgJUmWlFjQWn 3MR6ZM01yxevzdRla8Gp0JQlkuaOBVQZqkvGgjG89sdiy+6jAmxgtP6bKU8fkSR3LKDKSStq/DdT oj4ia65ZQJWZutv6b6ZMfUTWXLN8ubWZumAtOFNiPSJp7lhAlZkax8iUVY/IggsKIOWjDqdiFqSU ekQWXLN8idpInbNFRaacekTS3LGAKiN1l7XfTEn1iKy5ZgFVRuoua7+ZkuoRWXPN8iVpI3Wntd8c aGskkuaOBVQ56VWM/WbK00dkySUJYIkaPK0k7Y1EllyzfIGHDDTboiJTmj4iae5YQJWbXmk24H0H oMo4K2rsNlOaPyIPac3ypWjjvKK12xxpayWS5o4FVPnndVu7paxvRJZcksJ5avuszZPp7jsAVU55 hRf+SoXHiHVEexZQ5ZSXf+Gv9JCOyJprVjgv7ZSXm/113wGo8kWTyuZMr4dEGs+SAkiZ4nW9sFKq gkZkwTUrnE6b4nXOVrrvAFT5X/UAs+SFHh66kSW0AW04AJX5lTn93+Lh9Nrl8gtrpBKsj4kPwIYE UJlcepsP+RoGpswsWQcsVLu1IZXT9cEsSeEM2sri7H9bHGAcC1cvczDkJR7OmjCMNQrVvibyBgeo rCnMfrbFASoT8m/zlNdwOOMjw7MOtcEB6lRu9qctDlB7ymxEWzycSTvKaR1ngwNU7vE5GmoKVSuP j7nHBx3FA//o+HXwxuH5pFPRPkYNH+Qm7YzdTW88PDdG8qHygojT+0H5TOtBj9IHJXeOe8TWI/AV jDg5H4+qKdDvq1709ju2hlMOXMK4fM6ypNyQtG+h4dQvuWpwj/7uIVfz7da5f3A08JBqQ/tgH3Nt uJ2elcPl0POuCfdjYervEPTS1Qan17ZuXg569R1O+sfYHrO70nCdzf1rA21PqC9cmzWchhpunmpo 2xNqQhJONaxwZekRm2hh0dD2K9SEMkU11VCza3IT1Cv020uH2BpCM7q+fHXdea68wKFWeY8tCK6v BvX3bHbPX31zhT0aorgMfzCI1XIDj7EfMpkEn0KZZT+msg79IMtK9aMua9kvg6x2vy6yH/1CyY6N K/e4lO3GvuGFb39I1Z5n+/bPLLWiKt+sqMlS44kXcUTWXLN8vrRp385mqfHMh46kuWMBVWZ+XyZL jRdezBFZckny2WmLv8/5DYAMraJEktyxgCrnr6hJXSONjwMLrilA1VENxVaz0dHGSGTNNctnrx+J kG1iFl06dCTNHQuoejkqavLZ6FE/jMiaaxZQlZwGXLRZ8j50ZMklyeegfT/QzZwly6EjSe5YQFXG Gm4456QZUOCNyJprFtAUNWqq2XjTOkpkzTXL51ueSaBhTvKgQwspkTR3LKBBnQk/537QoZWUyJpr FtAcNGokIy2kRJZcknyOkjAAdPDSSZJq2xFJcscCqkw1XA9TZU1aR4msuWYBVaZaUWvFVJ2OyJpr FjIXnT+fL6yYCsIRSXPHAqrz6mKtmHabA+stGUinlKP6/MKHqQwakSR3LKDKVCtqfDhRgTUia65Z OosEmubMverg/PTAgmuKz0U7qo9zNg+ZcOhImjsWUOWoFTU+nBxNWSJrrllAlaUiFzGS96EjSy5J SJiVo/pgfTh5XO8RIbllAVWO6r314RRoaySy5poFNGeNOjP1QJOWyJprFmoDp9baoSCYNG+atUTS 3LGARrXY15tZzkiTlsiSSxJAZagVNIOk+z0iKy5JumwDeFoXTgkeNCJJ7lhAlZ/WGsC4MFllDyy4 pgBVZlpRY8EpN7EeWXPN8sVrM3XZWnAqNGWJpLljAVWGWuuZed4YXvtjsWV3lKLKSWspZPw3U54+ IknuWECVk1bU+G+mRH1E1lyzgCozRfE4702mTH1E1lyzfLm1mbpgLThTYj0iae5YQJWZGsfIlFWP yIILCiDlow6nYhaklHpEFlyzfInaSJ2zRUWmnHpE0tyxgCojdZe130xJ9YisuWYBVUbqLmu/mZLq EVlzzfIlaSN1p7XfHGhrJJLmjgVUOelVjP1mytNHZMklCWCJGjytJO2NRJb8L/vV0uS4bYTv8yt4 JFORDIDg62ivJ4lTG9dWWbErtZWD7OWMlNVI4zEnU/736ScAgpSSWy57EEV2A41+fui+vqseEEMi t18OFT216fFJMm/tQm6CprbLAfj2AuQmwAncBdz21ObHp6h0fVc9DClw2nYJt31LoQ1PknlrF3IT /LTNEm6p64tPEXl1kzcmhU8gZ6B7ewFyE6S0fgVfafCIT9Do9i7kJkhp6xV8pYs0PkXm9V3e2BQp rcvx9fYC5Ca4uGhl+55uj/Akfa5uQVYCitauQClNQfEpAq/v8saloGhNDqW3FyA3wT/AgIXLB7p4 qCIHzwrd2IPMBPyGvP2/yfemTlGuX4FGGsFUJ0mAG5uQmYBct82T/DobeQmYdUsEHGh2Y5UG41SZ q5u88SmUtTn+3eQjs42Og2L2i81X+d5AwxB95AG+ss03+MhMoMnneHaTj8wEhOptbvJ1tjftrMNb ItQNPjLTVi7Hp5t8ZKaYkgPRTb43XYooZok4N/jITNDjKRKghYLJ45SvOHEqQofxViS8BnPniZKC zyLCicCEU6xhcfHeaVCRU9IWtJi8J2pneAXdSSfq7ZysaHmFlwpsMXFOs6HJ07eFOufvlgkm5FuH etV9HzwqhC6FLSSY9CJPCG623s3EQbvNi/XASBCVgMAHqs5AaFxqlcPaSO2GfnvmGPj2PnUdEFzq W4hd71PvO0z0UwzPIriBYA2DPxAoPB4uOLYagYYIjZjqOTwe+hFvErW87cOKloUOItRzvDz0k12b mOqhuSYwwXGFvuuwoGWCZ5xT94HfxVZxsIchbxYC79QbtL4WrJt/aXDD7khoA8jIgT4grRBER02y YIRkYbBS0zT4QRM5eEpTPfhSiyF4W8slxEMLKkQsltysKE93P9xhZ+ULaNX4ymjFkFC0XZDAZ5he qqUReVxcnu0UQMpktKAOEyzLUILsuiYmWcTQVKOAeHm3c3ypwzGiaq3+oS+97NMzFjK0QQmqKiGo ui4mWbRQNY4NpNkTFaMeM7RSnV7c7Lh8dVRo+IwVGRAZP0PPQFgXENlLZ1InlzoCmk87zy0ndxQ5 E9Zz25V4YSkjZh87MxDUmatiZotWVG3kThBHeJhPNKcFhVqpNXEmbomeWZfRBHO91paNubMmQNkL DeEq8Dj64JOHn96FO6nFxgK02tAtj+NUxkSOiX1d0+Gwh89VUXF1xnE8WyK4qKjWoDtbqvalqPmG BZMaWXwN0jwqhs91aemGBZOmBmz+gzQaW/C5Li3dsGDSxIv3i0rr3FDwc11auiFjWm43EXKDtJ7S sF/323zDgtmS4ib6ra9pfKnXdZtvWDCxtzOY5cshdF1aumHBdMjrkxnC0vRgrwlL1mc8OgKYUbHB Y2Xgc03WbP2C19FBPvpsaIeCn+vC0g0LJpCBWSeqUTyHK/Gcb1gwHTnUqdOwwtelpAsz5lNOYID+ r4sO/5sgUxi+zSPTYzkS7ijsfMGpLzj1Bae+4NT/EaduwRPOJW2hP5pMdBodtFXXeXXQ2UYH2kEb Yh3yBu5hsQXmts/wBFUPOsgZnrHqoZFBxLCa9eBFR8NzWj04WWG33Khb6QQtt7D1YGRAsjwL1r0O coHQSfdveZ6seyO9+grB+GyLEFRo0EuPDQRVDGphpjjKzkwTb4jx4K/ep+6JHhUHAkHGFHVxz5rH IPQ6L2mYegxyMgREgkytYYvOtUGoTr56rLdivSrm7SBCRXXvnMwAYq13MAy20R3eeZlSxV/exVwQ QhfiRj7HPK2vEVjRZIsQVKjEPh4r6RL1suKOoDknmHcmKM56qa2ao8EbmsXBXxrZ6NFBpzn1eXCg CQ6UaprV20kgyeD11w+EjPA+K0yK1qwws6q0LqvKus2Sqs2ybmizonRZ4komx5o0eQ26PqtBnxXY /FtFJvUlZ8T68j6rp5lWEW1iOdW5YXaGR+A6RoaknDgZknJyfVZOdh6nXpIyqS9ekdSXm2dDqECt L9EjrS87y7mQHpqVIaOSgnNZvXFSJgXnfVZwXKKhnBYELYVYTT4rJrYsKSa2PSkmk1cTn5FUk8tM H9oMfNqsluq5f4OzQi1lAerl5vtmdwfSu6GjTl1e6wYO6E1boEAwZ/cUO/mP5T8q67d9eXl9qTZw hZbF/a+vx+enagMmt+V4noq/jMIaq3/u/npn2y0IwgYSpBmU9y3I2/2Cj7e7sqh2/7r7ardroS3Y PdyRsaIMkMDRxoMqrgUpBmxBZbbGuA4lbPAVRIOcj+W7y/nh+Ahqtdu63FceFJgq7KjL4+VcOCJs q3rrSyvvG8D50tNHQaqCGj6okXklquIxOVkVVoCMgRfbBU3OcLIrx1/gjHI6VhsIUfnvI+jjGnDe 75WFI/e0hnTsyuI9fDrPrLEyJfkQ6Lhoa8taX96O04E2Fn+qNg1Y8w72gfTifsM7PuBpvrxEGXrE Dv4hB5S8f3ioMCh9eaxgmClJ2WJ//lTsC1lyoZNepyPb81i8p/8aZBf3k+w+jLJajAbmVPwGWhlU t4K6LI8TCT/gPvK0wZ6983WD2fCx/FFFsCYPMz+Fc/aTOmHcs7zcB/FU+p4dyzsP+9/YzOLvQIGy Bq1NefyVDR2Lb4WK7uOkBkfhinPx/asSfh5DdKIxDZQxGEMp4dqQEzXnxA/j9AqiMR2fC4ogvo5F Bcf+VG081tTXVV1+XzxfSHhdTqBph7mJIQFDACDaEpKc3OFLynVaOIqLPIRC7fzb15AG5bs/Ft8J 6wMIB0ly8Cddh9mCxmpa1JwtsPZZvi/PqqwQTuTkgaID29gHuz9ICS61k+1gdXhd2ngR1plUmXmI Fb2fKM8AFSFkIyWYxdR6Q3UHDjVKOrAAkXsRceof+hwFrNSAfa4pBFtO/XRUg/R/TH2FcCcnvf6s vh2DUYlrvnk9It4M4L0a5RZqy+V1GnW9HKrOUdF85PSqgSg+zQ0474XB+Ql5T2eIQ2Igp4uQLic9 ce6myzm4O0ao+Cye5tBooN4qi5Wmgg6BXkwXFfI4hooFYpKkulhyLSSGGq5+Y3y1oZh6AdgDISuI /Uy5CGCImKtEBlwPgMv/fDAlbAN/qtJXjGbwhqgDqfdZ0KN4f3w8YBBRWAjKmQEbXk+0/MTCiz+j zoPIeNxQWPvynmuNcohRqmGU8kHiURdMXFm95NhQ7sWQUXVYAU1yjQ04YwRnAEkxZaEhobuk0+x3 lP1Wst9x8hAXkgkiiVmG3Amd2HJoDIZiFPae2MJkScUlSk5lvGyLDwizuFL+6O6h+DZ4O9PNgxuP cPtalVo8vFwqbGIokQnQvzsfp+NepE8XeXnBHGOJrNYLZdoCi/M2AzIqe7nf3f1nANYsgdIKZW5k c3RyZWFtDWVuZG9iag0xMCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTcgMCBSIA0v UmVzb3VyY2VzIDExIDAgUiANL0NvbnRlbnRzIDEyIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3 OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTEg MCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQ0IDI2IDAgUiAv VFQ2IDI3IDAgUiAvVFQ4IDEzIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDMxIDAgUiA+PiAN L0NvbG9yU3BhY2UgPDwgL0NzNSAyOCAwIFIgPj4gDT4+IA1lbmRvYmoNMTIgMCBvYmoNPDwgL0xl bmd0aCAyNzQwNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiexX3W8cuQ1/n79C j7tGd6Kv0UivdnLXC9CigKdPQR7Orp1LsL4rnLRG//uS1MeMxt5kbTgxcRAW2N3hSORPJH8kdTp1 r6bJCyWm6y70wQkJH/rjTC+tdGK0o5huuldnnwdx+ZneS/H5snv187kSHz53spdSDWK6LP/uuneb n85++cd253u3Eb/8vh37YfPl6vaP7c7Cv3/HH7FVejNtd8r2enO13cnebj5/EWnbfqtB/GvcK7a7 YPwA4n/+/a/1iv/Qgg9R5fU2LHRtd64Pmy+0TLyNT3H5HvT1fvO/rQqIUMXdLv7sSImODzL+/AVg Io5aKkmZysfZqSGA1wL8fT+97aTYjapXRoNLXsMTegidA6+nT+h2W9w+hjE7Hv8q7ZLvlexHh+6P m95MoEL2g9QxBkp8FB0s7I1TAoz3gxZG4xY436jF7VV3HSN3dg77nDPw7QPG+/wMdr+FP59QZMWd UFL8Tbx7L8W/ZpV+7J0VRvVeeICECk9POmtCr3SxeNNZ60GHEk6OvRb78jwE3xsS5B1R4X6tYt9d fx+1F8eoVeBuv3iuHfpUsI/WClgLu6weei9xt0Qygnpt4Q+uhuz0tF333q8E8iHvoA4VBQNYQoHq QxTY3vliZb82G0/KCIqRvSYfD70lJKG3tMb0tMeMYG/5nK0QKTCDdO9oA1DWVcAwOiTwvXLZxH5l khMKbWjJEMbe+hQWKMCLKKQMrAShigLUFy+XccJi7JdJWgRkZb82yw+KAx+XvEIovrd2EQws+X7x rBXRco5FMjNHS42U3XNmKg/FdZm7tVFeQJTAD5WU/PIwj02qr/d4nF1ealZZkXO70LaysvLFD7dc eENOPYarDuwtXWoN7Pw6V7OgrKiMMgNSSJP7VolFIV7mahHMeXcsV2srL255TPX2HhcztbRclejD bMzxKOQ7zMbKLDco1ST5rSGyTYQvNBG2wDANTBvV26jeRvU2qrdRvY3qbVRvo/p3HtXbrNFmjTZr tFnj+YDwoS8jKDw4zAMFJ/oygsKGwEyAtFsLi8sCGyDt1tJuLS/NylYP+ABp9aDVA4IiBRiSWkga FiiJitsM2d4F0CJur7rr+b0HRVYY1XvhgaH49vRkwc4cW+uJ0E6Ofcxenwi+uiEkhfu1isSa51d7 cYzalIjlufbOU8E+WitibYHhGRigT6JOfXF9sLtpKmMPdLeVd+ZCV7pbZrCx6fpQ2l1lNlUXPlCq G+wx/W5YlT2rU8k63O88lfpoYr8yyQlFfXGNYZFyGYXS+RaCUEXh252vCPLIVJvlB6W6vC5bYQqG CinP0vPhRpijtZgXDjXCyigvIErgh0pKG9XbqN5G9Taqizyqt1mjzRpt1mizxvMB4UNfRlB4cJgH Ck70ZQSFDYGZAGm3FhaXBTZA2q2l3VpempWtHvAB0upBqwcERQowJLWQNCxQEhW3GbK9C6BF3F51 1/N7D4qsMKr3wgND8e3pyYKdObbWE6GdHPuYvT4RfHVDSAr3axWJNc+v9uIYtSkRy3PtnaeCfbRW xNoCwzMwQJ9Enfri+mB301TGHuhuK+/Mha50t8xgY9P1obS7ymyqLnygVDfYY/rdsCp7VqeSdbjf eSr10cR+ZZITivriGsMi5TIKpfMtBKGKwrc7XxHkkak2yw9KdXldtsIUDBVSnqXnw40wR2sxLxxq hJVRbkD40JcRFB4c5oGCE30ZQWFDYCZAlMAPDSf55WEemzSp3eNxdnmZfsqKnNuFtpWVlS9+uOX6 2nsMVx3YW7rUGtj5da5mQVlRGWUGpJAmT8AlFoV4matFMOfdsVytrby45erKu+RippaWqxJ9mI05 HoV8h9lYmeUHpdWDVg9aPWj1IEKRAj80KPAZ+BlB4TH180DBaeBnBIXJyM8ICB/6MoLCg8M8UHCi LyMobAjMBIgS+KHhpN1a2q2l3VrareXFWdnqAR8grR60ekBQpMAPDArxz/kZzanEQpt5WgSYlJiS mp4GRIbItSyPl4ScXJ/eK0MDT9pcnkg3rM4CQ6Esm8GItLPy+HjZFePpfUaWdtfIL7uLk25pEUoI 8E05oRRmxe1Vd3oyn27QaYwtggHTrZgcRiw5BVJ8XJw3vc/20u7ySNoXB7YBrMwHtiOGdfYmPS4O nN6XE8bdNfb6wAO+w/MUiyqxZbErriha04rzTvbOGpG/B60pRXrr8DF+G4hulS60uU4XxPj0fMHd Nfg6YUKdMN5XCeP9KmHw/SJhwjJhkvb7/osJsysZcw1e8MMgyjekIY7ZoAm5hrsKaaJgwLq8zCJb JZFd5VA88+DmreVRz5yJAhlzJjvQI8bZwfS4TKH4vgCTOaMWwC+pPB1MkPuHeSQljBMrBy9CCois rc5jq+PY1WmWBIhba+DPyYdWJluZvJ8WLQlaErRe2Xpl65Xf4kNL/Zb6rFO/RYZrZNoA32a3Nru1 BtbKZCuTrUy+SJlsSdCSoPXK1itbr/wWH1rqt9RnnfotMlwj80xFaVRW5G+nqChpCdUDsY00BCka Q3ZAeuByIrEOuD596xG7eNllAIdNu2ATeCqOSWDFk634rWpTCkvKDQiG3pHAYhj3nQa3USCLQGH1 KVv2ax17DPV30XuBZzBQCPO3DvHgFg4M65zBKgm5IQaIYT50gFXlW7q4I4FxDl0F6JSEYbQIYmTs iDbitxlGclfGGH18M58C08cfd6xaB7nr4YDCQknNAtLmaFu0IybOfqUiefBBh+TcGTDfbxYgSbAI BpDNVyuiILrsq2lJqJeq8zGKanB+tSIKouoHUefA24SpCEJSDXH1fiFojGuMa4z7sYw7nTrwCbhL wif+gz4MAEAnNliHUKabTtICuqRKaYyYLrt3m/Orre/N5ha+3ea/W5hkx00WvZ/edmbsg4eJfuhl ALdNr2m3GnA36RnFdAd6fjqDTeNGnN9tNWTB5uOX7c6A4HK7Gza/kSocD0wQu6GHBq1R1Q41DIp0 RTXn2x3MBxvYDOc0mz9uf/1wRZvfTIi/H4jp3hDVjYRkhrO5ALGxArJvhKoSckVxDi8iPnihyLch 0PjlvAY+xcUe6ZVolTgBNiTVLGMs1Jui/aYz1lJUR6nwLrIvAhcSEcoWr3DLfq2DmPFd9F7EA4wA XdXgFdDlQSNK0kBWBMU/cct+rWMF/hn1RvAxN43GbfjS9ZYMqADMR4GN1DEwWeKUtxCMRAkXNIYT DQxUI+YVRoGyonS/thKP9oKWHc3Ko5SxtRhtU2IHbHmoxgDbK0HWO8ZR1xjwso4rqFBmKHNgktuT lf3aLDsoytN9IrFgGQ/i7pxqC4GiMuvCgFcmEEibIpYDJKG82CW1aisvbVlrauPJl+h+k8hDsxLu snQLWggc3M6W3pYhBSjHQ+mUpTkHlaEuO6+ozXKDooRKVa2Qh7yMmGSqlM9JUSOp586xrM2uqgUD KJE8ye3HcVaDdw9wNq3InM0ULWBzcGuz7KCoULrMisTZ/UolNUWQszPH4z6Jc0LnXrYQJFZXZtlB KfTKTe4+q4fk/kewOpM4Z2kRlK5XmeUG5XGTZRskeQ+SLZR/mlC2OwGHQZwRlHYnaHeCdidod4J2 J3hGKHwGcUZQ2vTBpOUzgtKmjzZ9vDgzW01gBaXVhFYT2o2k3UjajeQZofC5BrCCwojMjKDwITMj KIzIzAgKJzKzgXI6db6XgxMSPvFfDIB0wjkyPt10kl7DeLOTvZRGiemy2/z88cPuzXb6hEIVjBM7 Bb9qFNPrDpdZi8vebc7vtpCkw+bjl8vftu+nt92bKSk8P4OFMJzeiU7jdIrns0AS8IiGc0aPQBlA 7Nalw+DzTWehoszr9905quwHqSNOFeL0O4AayBlDmbMLaOz2qrsGs84Z2OCDh7mNcHiLOOaNChyB yQNOsbjp9KTTECZMq6QVUKJiTE0YtgeEWQRwj6Dknbeo6inEVL7+HkovjlGqQiLiLKhc9lSwT9AL eEuCaUhr6iVAeprptUy9RELy/p/9qunR3LbB9/kVPu4G2Bf6tnxN0B563b0VvaRIkALvXhYF8vdL UhRFW7ZmukgyOhiDIWZE8RFNiY8eBQyHTiB+aAOxPGyO5UnGl3PuLPOqidAzNJDLu6Cs8jwuW751 olTgHUOPOchgxePvLN8lJhU6cHA70l0iA7JQKneJgyak7jdr4cSW21ZeiA74gZ57ZZXncdnpUoFw Q2PUvWWDjFH7IYdRNoguUrUfduMXYt0xC4yLnyOnsw7wKs/jstOlYlk4lROGG+QeIej9MHzbtIFY Lpe6H22humOGxVc7pa7wcTvHu2VnS8Uu+IMEI87rrl4Zr+vqWnY5rjKjnvCa036VQzX++pVr86xF hb2hZ0HTl32oRYULN+qNOenZOlBn7JedLhVunnaXyX5IA9aerXQuZ+/NPXtY5b1XtvzMOutIbi9+ trSBy46s+yENeN2Ru2VnS+X/ko63QnwXhXhvy5Tbcgv3W7jfwv0W7rdwv4X7Ldxv4f6XC/dbfdzq 41Yft/r4k1KZqJknSmWiZp4olYmaeaJUJmrmeVK5XzWTPCUmSuV+1dyvmnfvzJsTpkrl5oSbEygV s5hHNG4xKBrsZuiocNm8Q/uJDta3X15+VX67eIt5gPoL6PvxBzl4bWcxHj8K2jLSaa4Dx2cD4j2P AKVSfzjoz28BlTPYBnaV+d5kvwMX8r23ZcptgdYpbXN4yp7ebgnCTm+3Q3mE5NrtJt2bmfWkv3fL Mr3Ok8r+Kfum604Wqqzn0iOZ8XXnHjbJKs/jstOlsn/Klg0yRu1Hu//qBsHUTe/H6/dfuxyqeNov O10q+6fs/kIs+wErFuEjA5cXolyZVTdcX4i7ZWdLxS74gwRzC/dbuL+3fL6F+1Sp3OrjVh+3+rjV x5+XykTNPFEqEzXzRKlM1MwTpTJRM8+Tyv2qmeQpMVEq96vmftW8e2fenDBVKjcn3JxAqZjFPKJx i0HRYDdDR4XL5h3aT3Swvv3y8qvy28VbzAPUX0Dfjz/IwWs7i/H4UdCWkU5zHTg+GxDveQQolfrD QX9+C6icwTawq8z3JvsduJDvvS1Tbgu0Tmmbw1P29HZLEHZ6ux3KIyTXbjfp3sysJ/29W5bpdZ5U 9k/ZN113slBlPZceyYyvO/ewSVZ5HpedLpX9U7ZskDFqP9r9VzcIpm56P16//9rlUMXTftnpUtk/ ZfcXYtkPWLEIHxm4vBDlyqy64fpC3C07XSoTNfNEqUzUzBOlMlEzT5TKRM08Typ2wR8ULuK87uqV 8bqurmWX4yoz6gmvOe1XOVTjr1+5Ng8V9U096wzvQy2qW3mnrnu2DtQZ+2WnS4Wbp2lk2Q9pwNqz lc7l7L25Zw+rvPfK1kL4RUdye4VHMLuBy46s+yENeN2Ru2XnS+XmhJsTbk6YoBGnScUs+IOCYaJn wESpTPQMmCiViZ4BE6UyzzNgplQmauaJUpmomSdKZaJmniiViZp5nlTsgj8oXO5Xzf2qee+3xf2q mSyVmxNuTrg5YYJGnCYVs+DP559eDB6f3xdKBU9YzNujHlKUqHENME4o7mEQxUUc+CoRCdqPZnx+ +fHLC+hC+AfBy1/Wrw/Qggn2JD7y8uUrLw1axaCEjMuX8pdfly+/v/zzw99/+gga+MPy+fePcKTT h//89+MnDwP//vgpfvjt47++/OPlb19eggtFY4PWRkEaXJYGwSLU/2OORbEGt5XviWspwmdYFRLl X0jHZv4egowWumehg/btlxfnfXm18HLOx1JSWMZQjWVCN4ARz5ffWozfWEQHB6WBgZC4xHXAh0fB 6FbZQZSdfGzGwTfkLS/lb5SBe+iv8HG5nLS6ls22nJIK1QZSbbdYHimwaHmkQMtSzWGgMDE8Y0if ywzJjzG6hLtvpi8IS/3F3CUGGU3XqQcxTBUqZEuHAevqMmvYFm13i9Htsl/Mp8Ni7gB9+Ea+oFCP 787SV/U/76RUuxto+3HYsTccl/2R2ydxeuJ3a0aPu/gJ7w069BhvsnaboNxUUmCdRVvuo0EYuum7 2O2QtTrUvGjLqIMwdOd2RqB7UwdqsU2aZdDrKJs9N0DxGrxTOlCqplgCHYahOzrttn2qlCMbhhzE oDu3iocNKtVD0haJZdRBmM2hKAp2433do66LtoQ6DEO3YgRw2377vV20ZdRBGLpzOx1hffSp+rho y6DXURauDkU70HWp336/LdoS6DAM3bGdjhCRsI6owS/aMuogDN2b027fo0aqp1hGHYTZnIrWYHdA futQqaBiCXUYhu6kqu5R2HSoVFGxjDoIs3lFOaHcPWiigool0FEUer0qukPCP4KuVE+xDDoIQ7di 3WD3rMuoVE+xjDoIw+tCsS64T8h6JUIVS6jDMLmE2G3OyDoT+Yll1EEYuhXtgu0LQDvPhhGvQ2ze NOX6fMbUpI+aJdBhGLoV64K7Z+qVtFezjDoIQ7diXZDHPVnTaaqGIQcxdjPlqcfuhJq+gwyLtog6 DkN3UiXvv93RV4tlyKsY9Cm2RdXUI8ZFW0a8jrKb1WTrwwlHrx4bvlkCHYahW5FtEZVH1EDbI5ZR B2HoVmQLbtcXINCni2XUQZjdnCZb0KCx3/tI3y6WUIdh6FZk6+0JR6+Jvl0sow7C7OY124L7BJTE uVgCHUWhV5GtNyccva7ITc0y6CAM3Yps4e3YczTRaDUMOYixW9BMC+6eoNdc4Kol1GEYuhXTwmui J+h1ow8Xy6iDMHQrtnVrT9CYYvlluOv57SFZvOmEnTNp/WYJdBiGbkWz4O7ZOZPYb5ZRB2HoVkzr 4gk7Z1L7zTLqIMxuSTOtCycEnUmaN0uowzB0K7Lt2SSTLm+WIa9i0LepgnscP0KSKG+WIQdhdgM1 pAqOb9IeNS7aEuowDN2Ka509oehMsrxZRh2EoVtxLbhPikqyvFlGHYTZLWuudeaEonOgTRJLqMMw dCuutWA7UNL6zTLodZTdNk214DUnoLRLYgl0GIZuxbU2n1B0JqnfLKMOwtCt6NauHUW/MsMZo5kV 3D0hZ3osNAtpvRKGbsWsNp0Qck60zWIZdRCGbkWwNp4QMunFZhn0OgoEkOZXGD/S8isz0K2oFMZP GJieMM1SVsMwdCsqtf6MgenabZZRB2HOOE2l1nUM/MoMdCvitP2mZrplxFJO1zHoU6xp7RnZ0puq WYYchDnjNWta05HtKzPQnVoZyRyz2uiKok7dQklqFOQMKJigvMfajSegV9FgPiNPetTVvPg4jKLQ q1hwPVLn0O9M1Gy3nnDkRu/BktZm+CyMotCruA66v9u20QT0KqaDPg99+PUEZ5KmtNgR4XgCehV3 hY7xxhPQq1jKH6lt6Hdm3YnEEw4bTUCvVoMdg40noFeTTkdV4wnOZE055oSTRhPQq+jlaxsA/Qld /TzOeNLpXPCHTmR1otKi8Mir0cCTyCbkMhACDRgmD1D4GQaanMh4Jp5KtqF4oYGqYXEmDbSXl080 0J6i5X8rh23FNGze6IGpBrLmMByw+nirAXjZmKxD2gCDwmNl2y0LAwWj5gUDZdmaOb1vniT66wTr 9LeWt4qqBgxEp+sFA1QeqShs2barOQykMoN3pdtUGbC23AkwQBE28MensikO5ET51roqiqmg8nJ2 kxkrYTrUofRt9J8tArd+qQOVz25UZTgQZMZaZqTCd7WcztVacMEdbEXOesCzBqp75HzkWhwH6j4L Rhtoz4Z9Hm0giFhP+lPqeZSP9bnsotSiHmGpVj3kUs/aBlLx2iiyJ9JKddNas+3asfTqA6/+8ouK eH/Mo98LWpvdjqX9iaBNBmmkWUIdhqFbkXd0J4I2mbxoy6iDMHQrUo+2F7TJ4iXaLINeR9nsNdVH 010GCETVFEugwzB0qxsA3L3KTZQjG4YcxKBbndqwnUjc5GiLxDLqIMxmUNJt0ZBPtBu2s7aEOgxD t2o5cPfSN3l8dDTLqIMwdGelCKApetC4aMug11E2A1G2wxESdl4Hui3aEugwDN2xnY4QkauOqAHf h80y6iAM3ZvT7qPgA6RI9RTLqIMwm5MWvSF0OhCRqKBiCXUYhm4lhoPHi6pDpYqKZdRBmM2r1sPg 7kETFVQsgY6i0KtEcsCbtANdqZ5iGXQQhm7FusHuWZdRqZ5iGXUQhoJEsS64T8iaHrjNEuowDN1a aZszsqb3ZLOMOghDt1bg2wlZ086zYcTrEBRfinLLRdsh0meLJdBhGLoV64K7Z+qVXmbNMuogDN2K dcv9fUTF01QNQw5i7Ga0rPepE/4IRHpfLKKOw9CtxH5PKKujrxbLkFcx6FNsi9KrR4yLtox4HYUi W5GtDyccvXps+GYJdBiGbkW2/n/sVzlvZrsN7f0rbjlTjKHtamkDPCBIGzdBkCoYIAHslwV5mL8f kqIkarl0ujRTmPCnI54rUeIR6Q8anQIdT7fMqrghLMQWYLcHINDWu2VWxU12Owg7LMBX1pv23i2x qm4IC7H19qDRWI9Ky6yKGzY8Qm0BPpCWS1oi1bxk+4eoOWh0SqhNwzKp4oawEFtXDhpNMtoMUyo+ tgSptADvAp1ypWuWWFU3hIXSunwQ6FRo490yq+KGsFBb6k8XUlxi/WO65/nY1wqZrc3sSke1/rBE qrohLGQW4F2dMxX7wzKr4oawUFp3H9Q5U7U/LLMqbrZEqbQuHAQ6U2k+LLGqbggLsd3VJFNdPixT PvkgVkTAPY6vlFSUD8uUipst2H8OGJRmPyeqyoclVtUNYaG1zh4kOlNZPiyzKm4IC60F+BBUKsuH ZVbFzZYstdaZg0TnQIfULbGqbggLrbVgN1Kq9Ydl0mcvW4qUWkDNgZROqVsiVd0QFlpr80GiM5X6 wzKr4oawkFubNon+ZIYzRiorwLsgZ2oWhoVlfeKGsFBWGw+CnCMdc7fMqrghLATW3gdBpnpxWCZ9 9oICSOorjK+y/MkMhIWUwvhBgamFGZZWpbohLKTU+pMC07M7LLMqbs44KaXWbQr8yQyEhXDa/VAz vTLd0pqefRATqmntSWyppxqWKRU3Z7xUTWs2sf1kBsJxhJHMuqpCTxRlagl1UZqTM1DBBIGusdMn ICpkMJ/Ek5q6ti6+DpoXokIF0yqdKu7MLdUuHTSyUD9Yl1UM3wXNC1GhdZD927FpExAVSgd5Hnb3 5wnORClp9yaE+gREhXaFTfH0CYgKlfKrtKm4M2kqEg8apk1AVFaDm4LpExCVorNJlT7BmSwlxxw0 SZuAqJCXjzEA9Sdk9fs6473eTihOflwCw0KLvG/+GA28k9aEXAdCoAHD2gEFfoaBUU1kvBLvomrD 2oUGWgmLM2lgNF4+0sDoROtv2+9awmXYXKi/FANZShgOWHm7xQA0NiZLlzHApNCrlOmzMFA52rpg oH62rZzam3eq+dsE6+Rea6siogEDt5PxggEKT48onFiZYg4Dsc7gU9nOtA9YW58EGCAPG3jzsR6K g2qi7rV9FWupINblbOkzEnE6LENpb/TL1vq27dRBkc8wFmU4EPqMVGfEKnctnM61WHDAHRxFznLA cwnUzsj5m2OxDrRz7hxjYHQN8zrGQOi1epRbafexb9bneoo9Fu0K92i1S97j2dKgR7wlSj+Tnkrt 0EayTen4/vJHyFQDbFDP1fcjQ+yndM2dgW9KeXXEEDmgMKOmWqStsqAsLIkzOHGM+0B1OpLIKVWU vCgv8qwqoX+Alxn4zPoy2/MvvrCx+K48vMw20JZ5JBlT5mVia9CkDVb1MUkbJ6LhTjG91tRtzQQv +8QyGiE+5jEQm8ycacSkJaBQiIYgQwGlrcvT3fL8RLWAgkvMcyx2lnH/akD7AAf0RCKnrMucbjx+ IPX7XANqE6dRDSj+nkJzZol9s6FllptuzwONmDSvFI41YI+Elrokm6FXMD2/Pb6P3+ihxy5zARGB pOxUCTtDtEeqMXtBXG1FMTKNKhp84CNl/E41O2wgVbcYss4WcGFoz2zSYQOppcDHpbNRV4P2zCYd NpBqRTy9xpZcuao9s0mHBbRUieMV7mS1LsrnsE3zN4w6H7z+vZHw1NX488pmhw3Eotbgfdu71DOb dNhAbA/w3Rk9haVuwj6xSYcFpI8AOJZWwn1VeyKb5m9YomUH0e3EclV7JpMOGxho2V4sjQ60PBzo 7LCBmLpkWeavc47PExfwYx2oIv3ppL/9b0TmMvVFH2DETZHuNNn5qVM/deqnTv3Uqf+jTmnyhL0J 1lX1j7uTWu1RQnyMtrUOiMbW29bHtorbUttqS+ZGgb6CA62XA0/6HZnS1SbVlpvLPE+/PDcqvvak trgG19bPFrx9ciC3Rs7X9tHmzJ/0XK5ny+X6YcC6xcUupNM3Xe0mx6r6QFu3q7Ef+7S1ch6B4NCN UNnWPLZYmtZTtWgbbnv7eRgu71st3363BrU59FK8UfYmt33Uto22E3WGK3xeuHP4jzhS5zzP4L06 F/oMioZzkcv5PtA27+lX5uaRo+38zRs9DNR1Cxce6Iz11Mc3+V6MZfJVGhvx0z75Io5I1Js6QkWP hAxmvesj2i10/Th6ukwJ9c6aY/B9y4UUFv6fMo/Oac682tmJzJsvi21N6rhOMS+ZZ9bUc3lKvX5p R/bVNBDZ58KSfT4u2VcTVuTWMtC+kkeg40xKpcKcXvO6tpU32YmzUMlsc1N0DF8XkWxrrvm45Jqb D9PwJRXZV2eI9KscIv3m7GurENnnluSrN6jfWb5zIvfcmmq3mxKjZWfPpW2gJ8bIpTCT8inLXLKr KLAGmGVhIp3MnE98QWU+hTl+HA2RT5wEU5pQPv3u7aXAA24iVeT8r40ogPBPtHiK19vHqNjhJTYG ysG3v77gfyBpbz9e/vzlT1/h6/nLP37799dv8fX+cv3yr9/+/s+Pr99g6/eX77/+5/r9d4a+f/3L 2x9efnlb308Pl+zG9UL4wnVb/HIre0Mor9k07OMlAEyHAMJGexsTtoH4Wl/87uMLXh8kya8Op4RY FagP+EDXZf/KTPGsSAs1fMuEenztWx5SrJ4WU42BWK9RgPOzdH53ldgAD0U9v7vemgCliglyRl9f 41gXvO2ZdkC1Gv3R2q18TkScdhJT76J0KXEZoBtf6/9AzUS308dcLcPkx3xcPuYW6mWPbjSY+Ij9 uJY79SF+84n2qG8DfbPryX1+bZarNy/ifa8cl2/evjaQAaUALj/6myxh6roavHSk1XI+KW4IV0Gp sKMeZ2XNl7TMqrghnMdduS11FAurpQ61W2ZV3HwpnAoM75QUzG6J8tkHsVsE3OD4SknLY8N8ig/C eUQbrsAdd0o6nm6ZVXELxvAzWuGMdmNNl7SYVbobwtFI2O6H5O0lLbMqbgiXEfCQXvel+vuSlkmf vaD54re1ohH1ZiMtl7REqrohHEXQbxStlTX4S1pmVdyCcazGDXZ7AG6KZ7fEqrohHETQA9YpGysF tFtmVdwQTiLqUJ/spBTQbpn02SsYz2VPQ/eFRgpnt8SpeSHqxRexytxIE0WzWyZV3BAWehvsrLfM StHsllkVN3wohN4CfJDpRFLaLbGqbv35YdicZDqT7nXLrIobwkJvwe4BoINnw4zPLgHqfaG2HvvN nZG23S2Rqm4IC80F2G7rTFR9DcusihvCQnN9Okg13aZmmFLxCSZKwYXya9fpZMMlLbGqbggLwQV4 1+nkaOPdMqvihrBQXGxndtL7kpZJn72CSVJwoRDadTp5TPthiVR1Q1gIbi0uV9ZAh9QtsypuwWQp uADvOp0Cbb1bYlXdEBaCW/vJlfWmvXfLrIobwkJxqY1dSSNtvVsmffYKBgojJ1FzIKUavVsiVd0Q Fp0GtJh+P6uECjUssypuCAvJdeWg1CSmzTCl4hOskXoL8C7TKVe6ZpFVd0NY6C10E7tMp0Ib75ZZ FTeEhea6tMs0LrH+Md3z/NFQVjQeNDpTrT8skapuCAuxBXjX6Ey1/rDMqrghLPTWgdxsp5Sp3B+W WRW3YJ3UWxcO3Umm8nxYYlXdEBZ6C/Au05nK82GZVXFDWAiu87tMZ6rOh2XSZ69gvdRb5w4ynak6 H5ZIVTeEhd46e5DpTOX5sMyquAX4T+gtwLtMZyrPhyVW1Q1hobfOHGQ6BzqlbplVcUNYCK4tu0xn qvmHZdJnr2BvqbeA7jKdqeQflkhVN4SF3tp8kOlMNf+wzKq4IZxH0C3oznJWn8wIFgqhEV/4VfZj obZhWFqW6obwHSV8IKVT7pZJn70QFRIL29rjR3XjsMz57BUgHEJhYXwV5k9mICzEFMYPGkytzLC0 KtUNYSGmkK4HDaaHd1hmVdwCXB4hpqBXqwZ/MgNhoZsHrc30znRLa3r2QUxIJrwgbk806q2GZUrF LUDmCc20ZpPaT2YgLOSxnES10CNFeVr4pdKcAuiW0MayKao+AVEhgvkkndTctXXV66B6ISo0MK3C qeIB1F1oXTooZKG+sC6rcHeoeiEqlC5u+qhPQFTo3L0LoTohwNsqBC1sMqhPQFRIV1j1TsURLKLA h13u3s8TAtQaTjznW6WuT0BU1oObgukTEP0v+1XQYzdug+/zK3z0O8xUlmTZOrbdFkWBPe0ARbHo Ic2+7EzryaTdSYP++5IUSdGWn9KeegmCYZ5F8RNFiZ9ISzoNVfUnRKi+DOW4lpO6E1Br6OWlDkAF OqdhO87Y6HYO+I9upCgXrP9f6JKU1WhgI7Ipl25Bxzd6UCLPANrYTDGBbSoNBJ6xopcblYaBZySa YXqvQE6aZrR8L3rZFnLDzRpEHoi2f9nuQl5s82UGoLdxqzWpAwwK7UreLQsDa7R++UWWZc+pw9mo 7JcJk7d7Ld2KiQYMzN7GCwY4PBxROLK8izkMlBDLqTSHWgfW0iTCAFkEx5tPfCjB815l1RBLRqpf YdYZC2GGVN4Z6Brwayk5qDulQJeBSIjR6YwSrOgL32k4o8RCAh7j4QRiOpzRzKTXDMg5K0YdCHo1 9n7UAad8kuxW9D7K1vXGSnD0Tkv49NZLgDUv5Ag0c+SMNLf22VdS8wFf+vIHCXq41XPYc1fIAilq 1xRKySFrVEmoXTNUm9yaPXrXoK6DlYzaMUO1qUThGI9UB0gTPppVMmrHLORs61PobxpICqZKgrxt gzpD9rM7qckSuceC8To2qDYXNGZM2QaSjkclo3bMonP2XYgrygZ1GaxExu+bodq8FqBuq9wUsL+o klE7Zqg2FWuEhGhB58FKBr1tBaxri1jgjWOZi0B5sJJAu2aoNmVsnE+K3xSxEaySUTtm0Xlb3YL6 WP8C0kzxVEmoXTNUm/oWaLAti9NMAVXJqB0zVJu6F7i0DetMAVXJoLetogOGcVbbOpoonCoJs2eF 2mBW9E3VCEALRVMlg3bMUG34Nk5NMYlIFE2VjNoxw8rD8C2oT2iaOtkqCbVrdiiB4E07oWlqHKtk 1I4Zqg3f0gt5BKWDZ8GIt02wyjJsC+/l2h4UtUlVEmjXDNWGc0F9LNvh9aUWrEpG7ZjZMhPVywlV 020SwZAdm+iSJVwoLFqeXiYq7FUSatcM1YZwQd3y9OJp4yoZtWOGasO4UPO0rvp5sJJBb1thTW0I F8qmlqeXgGlfJYF2zVBtCDeEE55eIh2SSkbtmGG5bwgX1C1PL5G2rpJQu2a2uUG1P+HpZaa9q2TU jhmqDeOGqeVpVFvJoLetsLuZvNW6E9A8WEmgXTPb7aHaYY19RF2Qoapk1I4Zqg3l+nzC1ESmIhiy YxMnZ/kW1C1NL2uBE4mofTNUG76FJqCl6SXTxlUyascM1YZzqR09gKKL5Y/hbs/HNtaQbeldj3BU 61dJoF0zVBuyBXXL0SvV+lUyascM1YZvoeGNzSmtVO5Xyagdszh5y7fQmbXdyUrleZWE2jVDteFb ULc0vVJ5XiWjdsxQbQjXh5amV6rOq2TQ21ZxCpZvvT+h6ZWq8yoJtGuGasO3fjqh6ZXK8yoZtWMW 4ZfhW1C3NL1SeV4loXbNUG341rsTml4jnZJKRu2YodoQ7pRbml6p5q+SQW9bxWm2fAvalqZXKvmr JNCuGaoN307rCU2vVPNXyagdM1SvNegT8M7hrL4yI05QCNX4wlduj4XahirJra4Zqudk1SegdMoq GfS2FWoNxcK22vhR3VglY962ihAOw7AwfiTmr8xAtSFTGD/hYGplqiSvumaoNmQK6XrCwfTwVsmo HbMIl8eQKfDVkYO/MgPVhjdPuHald0Yl+XTbBnWGMuEF8W2iUW9VJUN2zCJknuHMyTVU+5UZqDb0 mM9INdMjRXma+aXqGUXgLcONuWHU/gTUGhJcz6iTmjvxq1yHrhVqDQcuR+Ls6iOwu+G65YQhM/WF xa3M3WHXCrWG6VLDj/0JqDU8N7dE2J0Q4W01hBYbGuxPQK2hrnjku64eldkU+LDL1vr2hAi1hjfP eVOp9yeg1taDDYP1J6DWkk5DVf0JEaovQzmu5aTuBNQaenmpA1CBzmnYjjO2cjshvb4MRrdg+f9C d6QsRgMbcU25cwv6vdF7EnkGsMZmagnsUmkg8IwVndyoMgw8I9EM03oF8tH0ouV70bu2kBtu1hjy QLTty3YX8mJ7LzMArY1brUkdYFDoVvJuWRhYo/XLL7Ise04NzkZVv0yYvN1raVZMNGBg9jZeMMDh 4YjCieVdzGGghFhOpTnTOrCWHhEGyCI43nziQwme9yqrhlgSUv0Ks85YCDOk8sxA04BfS0lB3SkF ugxEQoxOZ5RgRV/oTsMZJRYS8BgPJxDT4Yxm5rxmQM5ZMepA0Kux96MOOKWTZLei91G2rjdWgqN3 WsKnt14CrHkhR6CZI2ekubXPvu3uB0hMB2hQvpXnIrLfmp2R3ZI14LhLniSOH8woqZZoZ8wfBxTo fjiDS0h1oBidgtgphYOCqSbWPYk4XYDddBwbdVNe+7pCg6JFiripA+LmKUidcnRzViYDr14o72QB zjspv4EG6HvmE2S3z1FmOLMdQcqAbPYGjJl08BQuSoy7gGZ+vzSgmV8kDejK1Zc5sgZl0dvD5y4D EtATEDvl4GbwTPwSihD0PpeAwsAaTUDhexeacxSvm42SWX53e27AmEl7T93DHLElQklNUciZ3xvK 70DVJr3rYHBUogaSUqEWbANRnkLV2QcNVx0YGYFKDt/zRBnfQu0NGiUVsxgyRYvoGMpzNGvQKLEk wadEwaiHQXkOZuY3OiqP8OwEbPF5KPIczBoclFMpM/EGK1qpgtbzqO0NGiU1Onj9tW8I1MSEc9/2 Bo0SKzmH961tSs/RrEGj9Khba9jyRL3DdAvMzD/oaAlQVsdynIciz7B28xvdQgtF09qkPBR5DmYN GiWW7g6fWUWj88w3znNv0Cg9BdRL0DC/z1HsxIPy5ThAjPL1SU//HZAbXHnPqzLhpoh1hHS+sdQ3 lvrGUt9Y6v/GUj1ywr4Ea6ryx51JqfTosrzUDrUMmB42TNyhSpcLA6Waj1z30So4IG0b5i1+e+5C PPej08QeBvxymRcI3H66VdTc5bmFmyMdkCYucKfoIi8ZSiEZ8sKl+slA6XqNyXQA3a2J3eDOKx0Q vz23lrrPSdqQoJHi0EmoJm4cNZZOWgyJtuOt6nk4Le3dar61ORUDbV8FUhtcWTTIRsUtKrWt4yFz uS9biwDm7eaj515UB2SvFL0Y9YBKcOdJD7kZKG4aEx5QRD5kXVOugXoVOBbittwk6l/UKd2m3EMN BF9UjRS9qTaWfNU12BI5PQ3Jln0+bUw5Dl+3NRO/wu9d4tEx7ROvNHUm8fZ3RTOz3qbSTJrEc8fM 8+su8+RgTfJxFtTk8/GQfCEdko+ibFPrMKCr1ECnPSjVCfvs2vvVeC6sU5ONo1GTze+i4/j6mFw7 plrZmEk1vz9Mx8ExyVdmmOwrGCb79sknXpjk84fcK/vQOyt3ruZiiYTJxX1aSCxjvQYl2pprzYAk ism1uM9vOXWTa7z1mmwlOOq4rGLyrXhu8s3tE05usEm4uA8wh8skXMmSfR5Rwv3m8S7DA+8S1ev8 MywJ/IUfaZpxB48vtZ7/cfzzBa7LOr5+/uflPj3M4/C7f3x+/vRyufcBvq4f34Y/XFl1vfzl8Y93 MD1lfOTXh5C9Hx6/A7jH9yi+3I3D5fFvd/cYIT9NVLr6BacUxa8eHxOUDY8fEAVrcvhXfqUAEnyM a0AHoYJwLiAshCMBcQD2j2N4GH77+vHD8+Uekmj8GV1exndv/P36cYC9zGH84fqGvxIsPoaBnIaF Y1m4jc/kE6+dFjw/is9+Q9XvjLFmY2s6OwktOI5bfs97iMV18hs9Tg9hfHeBGI5vF+wSxmfw29PA wwXu4Bj4N8Q3jRN9/C97QIr3GkK4fbgT+DXN6shHWHh6WMbrewzcOr49y8jPF8jmcRjeniC0wBIz 3IufWfc0TI5/ur8Xw3JL4ji8XpCUxg+gx1sz/P5yPz9M4/PFP+Txr3R94ngdvjy/PTEELHGVn+9+ KXD8X7HiDwrSPL4TD9nla3H0VVe8+Dj+6XIPT2kevwO3xu+Ha73IkS4yRdHhpVzmOeKtLEc0S4w8 37Ph13B/POHNEH7Eg6W/H366/uv5PR4M5MIAK/vxC9w9uOvjtg2/FMVnHIcFP33awAyYbPz3ZUKU AbcS4Z4+XSFePOmC5TscAKMyxvCZf1x/4onD22tZ8JOoniweqViB4YPk+PiOTbdBQGTVL5cMwfsP +1XX48ZuQ9/3V+ixd4EdaDRf8mP3og/3ocAFGvQ9i9htAG82MFL075eSSEqasTfjjbNmY8JAskNp yDMkj3T4ZeGgtaGwwUfIWg8FpI/6+vKyT+n7cH+qsYB1/8EifTVc5635in+9xJJhL2BZscjm45dP 1AxYYKALlhZYg2vcR9A75g9c/jN2S/qAF9xh/v7XUJb2L78b/OPTJ3q57jXqQQLyFbe9fN3iX6mK bahioG6dhXaiLFjk+T+3h8+7mL0+vDLF2mHe//1bGxDAamgnWg1fDlcm2MPqt0DKEZa/pdYwW1z+ GJdxMXkyL9lz6ePQmD8Dp8b0YeE/8wF2jPAZh8BMOIF2O3z182/s1ewOQOTAlueIEb72jy+fv33+ iN6/veAfh9CO5DEBO/xriwT724dwvTTdMMG/A2q+KWmWYATBN01RoHRjj1cZGeAyTrch7YebNSn3 wgFKy3HsUFq25h+/30WV8V9T7gyWH42WtMvTffymCb6mnX3PqSBj7I/CMPTxPmefiyDwVT/FL4If 4AGS1KUPyG+ZNt56D84GEXXY3u3yKugYEEVpA68/3mf90I9jVI4dwIKdAHgEjeGD4w1qoXGDkdjg o9LpBt9U2ecNExTXs8/9PEjK1PUCgw6LtigHQ+ApCrNuJLFHfrMhyKBgIG03DVhE3gFi07HT/TzK 1SP3USSnzD3nJqRMjjbq3Zw46L2UWtwAKW7Lnlx6KCNcMyhVPCaszDFlcAwivzJ0UYfnDFLcvANk gK36igy8oworDUprWjz33sI6MhDrsOEy66hHL033ywQmOkTCPF+GY2ygHXWUq0cmXtAtxMnO1DtK RU7t96lYhbhu2EVrrecZZXEFz1Y19TtFzvc3ZMrFlEKqAwJ+BhlYeuNnjN97SH3pnTcQ6+bPIUDR s4NrhrHc0MMo66o3eAdmJRuwiv1ETYw7ekDrK6cLA2s+xNHbWdjOk1N6xZL0wk/NBkpGT0cOZot3 UDoXBo4CeRnGEge/QkjZwN+CbZ8N2CU5H0QMyhiXdW7grBOO5SupcKFftVm0WdY2S9YMZ3cNFewd uqaF/6uuYQOBGHEk5K6Zt8DScNGuIRw/0jXjDMfprmGk1DVsoO7lfFDXUMa4rHND7ppxVpdLHDHa LDfbLKBhGlBy8O9gXTxqSCGDMejlqZmiNOrxY8mQk477uwmBFg5SP2YDatIfcppE51OCPgHodgb7 VBBSvmwYemxKUrbzIOvAn+8XwQ/wYBvf4RHPb5l2Cr334GCLM4ft3S6vdmMQoGkDrz9qHX+hOuJU sRxsaJKjSY0PVTbAyFbOeoyXNkwW6tKePVG9V2Df2GjrYK0a5WhQI7/ZgCc+T27TgEXkHR10Hjvd z6NcPTJeNzFzz7kJKZN06nPioPdSanEDza7cpAsPZYRrBqWKx4SVOaYMkqrOBrwDOYMUN+/Ayzn3 FRl4RxVWGpSs8N/COjIQ67DhMuuoRy9N98sEJjpEwjxfhmNsoB11lKtHJl7QLcTJztQ7SkVO7fep WIW4bthFa63nGWVxBc9WNfU7Rdb7W+9vvb9v5v5WlivLleW/OstVpatKV5X+C6l05bHyWHn8/89j a8IvXMyQKRdTCqkOCPi5aypv/Izxew+pL73zBmLd/DkEKHp2cM0wlhv6TbNx1Ru8A7OSDVjFfqIm xh09oPWV04UB8Ffc6e0sbOfJKb0CXVclMhsoGT0dOZgt3kHpXBg4CuRlGEsc/AohZQN/C7Z9NmCX 5HwQMShjXNa5gbNOOJavpMKFftVm0WZZ2yxZ+5/dNVSwd+iaFv6vuoYNBGKE+7LqmnkLLA0X7RrC 8SNdM85wnO4aRkpdwwbqXs4HdQ1ljMs6N+SuGWd1ucQRo81ys82iKkYvJlUx2iyqYvRiEnUxabNo s5yjYprBOlQycMCFc811tmlH07lmGs1DSJk5bO92ed214Us7yIzxje3D6iM03gS5s/w6dJ7vmxYA OPgqH5NJBng1tRq9kjzu5z5SQ/8Mv0+r/EJuu7E01Bl6M97z/T6VihN6MnDDddCkwT/0hotvO+oe D29Vhgna6FiCui4UORhs7HPXDZnEm5GC7GdB04eKwTHERnfdJnTjc2TxGPfABR3zO7lIp8JAYcZ0 pk0T3O3h2eOZhrh6G5+6eCpggP08oiQUwPG0qYWei8f/BihQ1oCaLxtcPBZyDeDQSSmmKsGRMoxl e7IhRtnPw4qDAorN9txVz/F8nVxZiqHHNmPDiJTEWnAcrBXchm3Zl+DA1o1bxRSFIytLXjxJ4Q0e rUco3FZNyju4q4mxZYxZHt45LBHGJ2m0gqFwu45lNicPR/ZpihIoXK0CysHAFKEbivNPNGNmsoHa bD0z6yjXjgztkM7WBfWISEN9GJ8kHpWBmfYK84qQkmCo7nvVryjdp+URXR6V5SrLVZarLFdZrrJc ZfnZkWXoYSEwVEuollAtoVriIjikMFcKDhHclYFCEG0FQRHDXBk4dBrRaUSnkRueRpT3ynvl/e3x 3hrbDNYZGy//vsUQMV1AKMjzwwZgmcP2bpfXXQu6zUDavfFBacLq433RcFRT3yfy9sDI+A1kWMj9 5HE/95FS9TP8Pq3ySz3IhjpDb8Z7vt+AV8sjuTxAJaRRNZEevdQ8nmRHLrU6QXzW8aXGZN7gXEC3 XBkUjxgpOKqxdN1VZ+vDb5rw6Dp+03V4zOPcO4soCUU9jAKKYQMUKGvA9x4bXOOqGnz/3mMDiaQ6 rDgo9UhaXoY89fbYZmw4dR3SdUlq4ZXbsIgpCkdrwi8eJSrLX2eoynKV5b+kLFctoVpCtYRqiR/H IYW5UnCI4K4MFIJoKwiKGObKwKHTiE4jOo3c8DSivFfeK+9vj/fW2Gawzth4+fcthojpAkJBnh82 AMsctne7vO5a0G0G0u6ND0oTVh/vi4ajmvo+kbcHRsZvIMNC7ieP+7mPlKqf4fdplV/qQTbUGXoz 3vP9BrxaHsnlASohjaqJ9Oil5vEkO3Kp1Qnis44vNSbzBucCuuXKoHjESMFRjaXrrjpbH37ThEfX 8Zuuw2Me595ZREko6mEUUAwboEBZA7732OAaV9Xg+/ceG0gk1WHFQalH0vIy5Km3xzZjw6nrkK5L Uguv3IZFTGE4pDBXCg4R3JWBQhBtBUERw1wZOFoTflGM0OJJCm9QnB2hcFs1Ke/gribGljFmeXjn sOWMu46hLTRimc3Jg+g7TVEChatVQDkY6sG3zD/RjJnJBmqz9cyso1w7cj3eltQjIg31YXySeFQG ZtorzCtCSoOhvFfeK+9vi/fWhF+8+KVodyk4RKh3GSgECXdBUIRodzk4pDBXCg4R3JWBQhBtBUER w1wZOFoTflGM6DTyOkN1GtFp5NebRpT3ynvl/e3x3hrbDNYZGy5/146JKW5svAE+QZofNoDKHLZ3 u7zcToFpkHVvfBCasPp4f+d6nwDHt5/vHCR/QCnTewjHBucjQH4h+dvPPER8l3f6tMapG5BpZKgy 80ak5zp9iuXB0kDNeux1F4aJWOX48iYV0/Uu9UM2tKmh5pkBMvTxeUBt7ZqUqJ4JF8+bWcz0lWJw wBToUi+PMd1h5vHpdPApmxO2PxsGniXidOTCcIGTo+8rZIFq6MP3HGU/DysPikub3BS4G6B06VLh YlATZsOItwxWw9mUbKqW69L8QU3Kz1M6hWcxheEY8fx38Y4NZ2dSE1QICN+NpQF6jMRCKgTF4VKB /6FqT0DYl/1bBRWFg8e8vHaaxh2eqwsaU8L5uOId1NVM3CrKLBXvH5kIE1O6jqcjSg5MKUgQV1Vl SVPP4jPtqKOKQ0KkwUuLi0GsI5rS88QKaxVLK//XCznh6bqkX+IS+K7P49P0w/wz2U6yr4wpCYZK PtGSTysirSIqwk/iEKR8BUGRIn6l4JAhfqXgUBEuRPrKQaIi3NyeCFdNoZpCNYVqisvgkMJeKTgE UVcQFCnslYJDCntl4NDJRMg8IAeJTibxnRuaTJT7yn3l/m1y3xrbDNYZG0VAO6YIMVuwCQj2sAG6 mcP2bpeX2wl6x0AUb3zABquP9wURsZaDT9SFqH0sBhnmuj/52888pDRd3OnTGqfUdmyoMvNGpOc6 DUi1IsIqAoRBsogZfKXgEDT1CoIiZfCVgkPG4CsFR2vCLx4nKsJVhKsIv1ERrppCNYVqCtUUl8Eh hb1ScAiiriAoUtgrBYcU9srAoZOJkHlADhKdTOI7NzSZKPeV+8r92+S+NbYZrDM2ioB2TBFitmAT EOxhA3Qzh+3dLi+3E/SOgSje+IANVh/vCyJiLQefqAtR+1gMMsx1f/K3n3lIabq406c1Tqnt2FBl 5o1Iz3UakGpFhFUECINkETP4SsEhaOoVBEXK4CsFh4zBVw4OKeyVgkMQdQVBkcJeKTiksFcGjtaE XxQl1ah7lMYdqrMFjSnhLHp4B3U1E7eKMkvF+0euRtl1PB2btpychg7cvU5TMtCOOqo4JOXcWxaD WEc0pWdqupUsrfxfL2Q5z9b0S1wC3/V5fJp+mH8m20n2lTFlwVDuK/eV+7fIfWvCLwoAKTpeCg5B Il4QFCk6XgoOGTpeDg4p7JWCQxB1BUGRwl4pOKSwVwaO1oRfFCU6mehkopPJLU4myn3lvnL/Nrn/ P/arpreO3Ybu76+YZWLAA32PZpugXXQb74puYiR4BWykSBf5+6VEHkqamyD2y63tFwsGbIsjkRR5 DkmZpfzQAMD/fHh/CptfPTlit0wwJM9UkE2xG1KqBLTZLyHmOsWV/29PIZqavPqFZvYCURzCkpXS XhXQKE/fcZRs2dT08pK2w6h8Vx/59Ojy7enjVWdgI2RQbaBj1hY2fP10enfV3WpfU3/L3dHg1W65 B6o/zSFedneV77Amp/X2RXl325woY+22OZRJvUWxLrvbynd1lU8Pno+X3Y3krIt3LYrteuaQVez4 cCpO+QW/o3MVF2tIZcm/PZXcA0biEL1si/rHYoQPjT73GEmFAQ0joQNIGNDRY4EPjZ5+L1qMjWsC ByWSwPGZ7pxjXPQ3qaFAFE2Fj+WUkyvz2q0jXlIY8JLCAS+J+WCCHtZVUc0Xr+tMT7wOLaUWdvGs yx4t/B1+8eHB69tC+R9D4ewmj0R+B3zW3SN/Y6i3u/Rh4uV4l9RlT06Pnl8S+rMMzjIoWJiZf62Z nw1wNsDX2gC/B/2J8onyl4LymZYXmZY5fc8ZbM5gszvNMjjL4CyDl8PCzPxrzfxsgLMBvtYG+D3o T5RPlL8UlM+0vMi0XGr6Xn3cSuExtfC4mGiKsEsR3p9cstVtn0JRcdcEwRfH7tp+v5HuXkAK7krY 6eK1f+c9L7Z08G5Hmc9+1UrRcVciUu6y0S3s4R4/MkLKc+4FnpJiOp1nRug2/xe94nykBcXJ8wXa KUpYAfi1M1pA9atPa8iyQb+/u2rPKkfIs664Y8pOcjjsqyv+xb1ArbjjK/Y6gSN1RZDXIfptA1Eg qc67oxGJ1LMZtuteZVQCaopiaX9F4MiBXm8TRApdEdgy1BfBvhoz7NhqPRGld0crz2055Eptjtx9 AyEiScUhhz5wwdLhfoOvpbeB9ExDb+EZjWrGa8D6GCOCIQkjVbCR/T6CsNt2xFqPO08h0LQMZl+a K1TUUff+BOsgAOsEcG0DMHppul/GMOhQCXN/IY5BoDsGK89tWXmBLqTBbsz6LhU1tD+n4mDiWc2e QesRPEMUf86zB4H6qSy3/h2ckCLW8but/Tpo07XYp0DuqdeODcq647oY6DBLzTimfgMle3fDCd0h UVEBskjOKIjrDsp/zoPSM4HOfOJHMAezNPu48YiRSQtXVYEGIwB/Eq22Q8J5JlArfqe89X7oEXiq AtwFsG8CQYnGQ4mhEUNajwKNOvw4P8KJqwSdYJlgeSBY2szwaNQgYU+AGkt/B9RAoE4kPAmBmiME zgUXRQ38+AXU0JdgHoYa3QHUqADoRTwUNRoxpPUo0KjDj4uWmAmWVwsWmmFWmuTodzSOnycyIZOQ sEMjEQ9PQS4LQQu67PcbEtcUyIimAplJf0kpD50f2fWNnLYHt39kBJOvCihfyXQ6z4w8zPnH6xXn Iy3Mmj1foJ1a7LZuabl2tMUtXz+dPrevPpUBlDfo93czj79RHuVVcfaw0ZccXmpaVFXgSJ1tTzf1 VzcEKgT2sS+qJzNsqW4VmacX6PCUw0MNeptAKr6+3MiiMcOOjUseK707Wnluy2g3NXL3DYSIJKq+ Bo5mUBf6DfJ2VZCeaegtPKNRzXgNWB9jRBBTdRNID9QIwm7bIc25eQqBpmUw+9JcaRP+n2EdBGCd AK5tAEYvTffLGAYdKmHuL8QxCFx7qXZWntuy8gJdSIPdmPVdKmpof07FwcSzmj2D1iN4hij+nGcP AvVTWZ79e/bv2b9fTf+eLJ8snyz/3Vk+p/Q5pc8p/Tea0iePJ48nj//6PDZL+SmNOTghRVxdDTnW fh206VrsUyD31GvHBmXdcV0MdJiloTqmfgMle3fDCd0hUVEBskjOKIjrDsp/zoPSM4Gn+/R+BHMw 6zOU4ogh5f1VVaDBCMCfRKvtkHCeCdSK3ylvvR96BJ6qAHcB7JtAUKLxUGJoxJDWo0CjDj/Oj3Di KkEnWCZYHgiWNvs/GjVI2BOgxtLfATUQqBPUc4cdZxA4F1wUNfDjF1BDX4J5GGp0B1CjAqAX8VDU aMSQ1qNAow4/LlpiJlheLVjmFDMb05xiJljmFDMb04tqTBMsEyyPnGI+vD+Z1YXl23LyLmuyKQD3 VVA9iWk1JSJtB31gwc6pSoY9KYJc7CS3bsWw94YLZgrVsPd2TXVD5Ch7X1wsgiQqvJcTG/vuveQh 7ZSxKthYx2ZE587Zp3WJcanW1avNclo83T6LgI2WHI8CCnZiQaw6KQv1Ik3HTnHqjBB+qt+05lhE K35TCFjgJRZZdFLwK+ToZljXxNLV60VjYgQmrDgwcQ2yzhI5zkbc6B8ObZZ1DUMisrIgr0aS4SBg BywDWAVx5/6mR+gvdNZL0d8MozYxJuREkpoCkNCtanZigBtBwOjlIkFUeJwIfBFC6+4kcl7KiocA TdX1saa/Lkg2eINBurJUhF0wsSlFOL9RGvkuoSBIDLWwUNaOAkvuDUeMUFd0Ei6NOCHYlmmBBBws EnAorAA79MT2PkjonGCKBEZCx9ciciCWotFJ+KOEigRG8iEMtFI+kEJvlcX7wElCgR6pO4jWPvVK k8URsNZjh2eKpShgx11Swo4o6N4kfBQuRmNmXFAVBc85qUFKNAk4PpSBIBw0YHo2g6BAvSsNtA6y gcNDaXampy0BYRt4TEjxbtCZD8QumBIBXy0aRgbdhANICTRCfWGel3jh8iABhUdYErm+aABJUKsv 0Xsfy0WQwkiCPbFAaJIkTZ2gBkzTpEVES0IS1207kgUMEQJGGEqCGCE8ORCei0hqfGaCB2FOYXo9 EiQ49aYktQhfHmCPWhstIp6lQli5B9Vr6Yk9mUtNdsJd7lymdQAeVMwKaNXQ0Vogv6Oi9FAsdUbW GFr4RsBuY2pi4GlR823WEgtBfEJUSGBlmIrgEPuQUD/A9q31Ro4sGrD3EhjlsgiSgRXR0agrNSV5 WQFUwsrAnbB18KBNQ4uSHauDHCHIuEFH8wp3FwxRcEYMaSlMUJHkplFrK0Mi4MQmGdRKmDXgomJn ZmtbCUafu4Kz9txVAZ5mHvUDrWkElkNxiOKnCrajzl1naoW7d73nhKowdkwnBTm2/scMSStGi931 RV57rJIycD2miKN4cPz2Vl44z6bRGII99Uco8blXSchIsIGBA05gIBnbto4wTpCDnqAzk1ZBKQVa J7XWbiuKcTBd0wibFNbcJrlk+lpMFZ9r4C4Z5iaDoawM87LfguthnD+z3GJDi92kPXadzMk1hKdJ 76X4xvCm7RG1O4EzbijVRNzouvB7zxWmZ7YJQ9uWHcg5NJSZDUZRcdRoFlZpkw5Sm3WEsQOJdMhx LRp5KNY+Czht6+Mu9MW2PE/yQbBJeU4jM3WH5Tz3Jd6ME58XP1QQ9Ag6/aFLJG0CeQCXthn6B7dP YGbIfXzKP3ngbhArsXXpJNzViTlIzfZjh93RQNGUzbBy7TOa+NiitWbr28GD3Hha+EZu1P2E+YO5 qfPH2YSC90xqbR0TnZPggKsJhY1pIGSNRuYTnfCyYFpHq8Re6PwW+O5tOvOMlDbQHSc+o8PZDmyN UyT1Bb4Yxje0Ei0ZSt/cmvmhBKCJJlALA7E8xryVaspd1oC7ZeV2rd5BvpowTAZGhwmGjMvCD4Hd H1XkBbzk4309lHMHd2+E/Z2SZHrsjip+qHVLPatghgpzwHOiRi9kxFceCyEJA5y8MkOSeuk2VlrS D0+CKHU/8IzKXjA6ZJBnyUmdNoId7EheHIkStbKz34A55Y+6ZU9KpfsqsG5QAvZFtO8oWlHsy0iS e7SgfSvMiQdmeLcoc/QFEce3kFrV90LW54FQfBcVQcgnoGqj/nC1u9PHq4YjykS9La35BRtBBXkK llop63DMZdPASruwBkmMl/mQA5RcX86Sjo91JcyKWS6a8FzFa0LVb1KHktHRhn0aHBCfxAeeJ++b D1qW1TCaI/m1SbcUPA06qt53NyfyM4a4GPqRf2kT2Tdpqd1zubk/mfr5v7en6zJckOj2VP6hBnrz 7fTPNx/eXtNd3vzny5e7t9cU+TfLl89vrwksb5a//5slH79+evuvm3+c/nZDJzcbFvxO5Cwpdi7U km/3QqXFFvgs174i8Oun02c65fayX367bfnw/lSZ8m1ppylyEad9HYDo8LurYjP/j/1q2ZEcN4L3 /Yo69hiYhpiiROpsw1cfxj+wNvxYoBs2Fgv7950RTJFZZJGeg31bDDoxpVCEyCQZzOQ3SwzPn+RB /9QHJzeHprHsHoll97QHarW4Mozy0Wt8/PDX3/x/dP+EOezqe3eUCwkQOWiK4dpwReHewpLdk770 rRp1QckogwnXDr/T0e0bd5I9+PjhmxJjwjdK1A3EdN1jLDn+rLMIuJS/b1bPEszWy3WVvZz1cFyW wv/+LWOU/fPRS1gGXybk3jsCqU83SjHt+43McsS9ka0++TaZRpXeaU9N2WZRhdFweN3SgHybjfhe dJQj3GD3A7uQRG0une7Bt//lqfv1tP162n49bevTxguTN5SmAzeUDoL1dERZw1LlKj1OzOW+jofd 1/UNpdyFwlUG+PK6Dlo3ZF7XpUH19zVuaT2Wdl9rfnlf/+GfX7T8efvlpz9/+aol+tuP/Pnx+Pbv L6LDfPvpFwP+zjtbO5JN8qmKf/zd97IP4+oNna7HV60oQtwuCLCEODikWj1okfj2y5evQdfy7R8/ //i3WisIKk1kaT9KPStoj7AVLymdS0Sztrk3otY9oMh1lTqR24VlQsTu1EWQcKH0+qwPwhXLuyBT Pt9S5ddWGsDIdvPVg2hFOw4Cyj0VwEc/24MU791SeoHxwW4FoaAZAyWwGftsD+7zN9sJSXORdScE Hd+FE4u9gIVnyaap/ssX/dbbzxrPt399CVqavt2PkPGv2vpoya6upuSM1Xq9gX7/Wyq4Jf/yVQ/R W79tYjqOe9t8F4fl4fm4/2CEQXhKJcFqDyZAhw3TFVTe5w1pmrQELqlO5cBXvP99vJcmrDIy7AsS qbS9ch1lgesDNYmriPQfeZIwl7020QnkKz/K/zGRZ2n9Vsh0gPatEGx3mVR7ULoXOE/kfjyetlo0 E9Y+zcF1YEbuBzrMlSOHoZY/jLly7t1c09GLZDXTp6/strufJewrKcJhW3z6li5v7r7Vf4pXp5dO z2tBiftbxYCf9tGn+23reOe6/90Wo1+u79grzxvueQzFmbrN/vTRY8c0voZYigzQ0cA1VE9mRTnX c2N1V6MdoDkLKGdlqCC1vWZ++Giac5aEvdiVoQFL0GkGefhIzRULaNnbhg6CTGKNJjihAEouz3pB 5F6QQ7NganOK6H9CS7Je4cewNMJFqZGaKxbQ2JIccdoHzfTw0TTnLKDOBErt0Wnu4eGjac5Zog2A tDxHvcUGyePhIyUXJIDOZeKJ89VLXg8fTXLOAnq5XB+InWbcHz6a5pyFC1qyR2WY+sE81kjNFQvo 6XLNwqTXZCJrNM05S0LCNV5RtZVBkomskZILEsD99OA2SJ7MY40mOWcBTS7X7Ac6zcQ81miacxZM e3O5ZgnfazKPNVJzxQLqDFXRbdSkWdZomnNWvVwM3VDcdpqZ3lajac5ZqHKdoe7XCxvmelug4IrC snlz6KDG+dZoghMKIGeoWswMHpxYRbVognOWyOYNVQvqwYa5d+4AwSUFqHPT/Rw9OIX48NE05yyg zk33c/TgJJxyjaY5Z4k2WM5O92Pw4CTHw0dKLkgAnZtqBzJ4cNpxtls0yTkLqHPTfR89OEUuTY2m OWeJiHdTRQcPTpGTrpGaKxZQ56a7jB6cDs66RtOcs0SbHmenexg8GNvaR0ouSACdmyo4eHDi2W7R JOcsoM5N92304JTgQC2a5pwlEr2byjV6MI3yDhRcUYDGlmjJqLZ7wSJ2R9Ocs4DmzaOD5MUZ12iS UxKaNeelkt77TGJw5Y9ai9db41fA86kvKGKsz1s0yTkLqHNSOUf/zazPWzTNOUvk9GYqx+i/mSV6 i9RcsYA6M0XK++2TWVS3aJpzFlBnphJHC84sqls0zTlLdMmcm+qRGIbJmrpFSi5IAJ2Zwl6GFWJN 3aJJzllAnZnCWocVYlHdomnOWYKNnz06WHBmUd0iNVcsoM5M9fIbLDhHrk2NpjlnifqIc1OtJIZ0 sk5vkZILEkBnpqieRkmuTY0mOWcBdWaKsnFYIdbpLZrmnCVqyc5PtWTuLHj9AlBnndprDIabWee3 iCEtWUCdd6InGiS5sjWa5JQkepcFl1Y1v2ExWPi1SMkVC+jh0hrV/LrErV4AmrNHh1Yhs/Fo0YY0 Z4kWFs4tg1rGqMlboEZqrlhAnVsG6T12/QJQZ4xBXthp5iVSow1pzhLUZG6pw2inbIVapOSCBNAZ Y9h6O12/ANR54PXCOC9eQDyVV7zHM+WIVsfOAK/eNZc4QOd0+YU9sg+7x2SbYEESrf+d0aX3Pjlz GJgztDS64MUergzpsk5uRQLo7OzsPXCJizZHzsyO0ewWOEDnWrG3uiUO0PlTfB+5M1i083Q+tPfm tcQBOheS0aUWOEBnN9J71BKXXW9xd4jf937KCxzg2fKxvfejnsPAnHl8tgcponz86N/44EZ84B83 3w1iNUk/zODOmy71DbWBD949p72ha/7hKgOsDB8kewPZ5oPTJpCQ8Q9Wz/cBDOWN1jmVF1oPmcoL oW43tVw82LyR64OAauzVg6S1pWfU3yaZeObcR9NpCveo0nl/9KhvSPQzSweaCjf3xOPksqMP5Cl/ CY2Oz7CuWHnBlkB/W8b7JY2i+6c8KEsQo031sCWIyeaqWvydy4mrwzq2+kIZ+BHKlVEW6LDGUyda 8n8c5djVVBxnsa2arOOe+Z3O43rO93nYNLrfdcFuhfbgrNZoHz3q4bdhxWphhSH1hbKx7mnVrXdP vG7OOzV1+965qxv8zm49Anf+2yF5OkbljL2Xo4o/nLTn7Xnsz01ouBVvNPS36rnhBmuRmisWUJdO zcxQIJ1bfvhomnOWaMG0tTXT5Kb+vj0DrrgWqbliAY2bQwdBJrFGE5xQACWX5w2nrhPk0CyY2pwi IXqjiReWvBfkotRIzRULqCsjY+7rTOikh4+mOWcBdccp5rH4PHcU/C2a5pwl2ga4OlIPxjDM/Xj4 SMkFCaCrLePZF5+QuR4+muScBdRVl/EYS9IzoiFr0TTnLEFPlT0qw9QP5rFGaq5YQF3Zqa4yFKvn wUTWaJpzlmiL6srRuL8P6TyYyBopuSABdPWogkMVe7K9bdEk5yygrkyFfQ4rxGa0RdOcsyRkX73G 0Je30GEea6TmigXUGaqiQ596spts0TTnLKDOUOPWl4YoB+htNZrmnCXh8oa6Xy9smOttgYIrClBn qHrqejXOt0YTnFAAOUNF6dtvocRGqEUTnLO6eg+FfL+FuHfuAMElBahz0/0cPTiF+PDRNOcsoM5N FR08OAmnXKNpzlkoU52dojgcJI+Hj5RckAA6N93j6MFpx9lu0STnLKDOTfd99OAUuTQ1muachXrc uamigwenyEnXSM0VyzcWQGX04HRw1jWa5pyFNsHZ6R4GD8a29pGSCxJA56YKDh6ceLZbNMk5y7dY QLfRg1OCA7VomnOWSPRuqq3O4ME0yjtQcEUBGluiJaMC7wWL2B1Nc84CmjePDpIXZ1yjSU5JaAOd l6Ll6xQxuPJHrcXrAJ2Naj+Z+6XOrM9bNMk5C6hzUjlH/82sz1s0zTkLna4zUzlG/80s0Vuk5ooF 1JkpUt5vn8yiukXTnLOAOjOVOFpwZlHdomnOWaJL5txUj8QwTNbULVJyQQLozBT2MqwQa+oWTXLO AurMFNY6rBCL6hZNc84SbPzs0cGCM4vqFqm5YgF1ZqqX32DBOXJtajTNOUvUR5ybaiUxpJN1eouU XJAAOjNF9TRKcm1qNMk5C6gzU5SNwwqxTm/RNOcsUUt2fqolc2fB6xeAOuvUXmMw3Mw6v0UMackC 6rwTPdEgyZWt0SSnJNG7LLi0qvkNi8HCr0VKrlhAD5fWqObXJW71AtCcPTq0CpmNR4s2pDlLtLBw bhnUMkZN3gI1UnPFAurcMkjvsesXgDpjDPLCTjMvkRptSHOWoCZzSx1GO2Ur1CIlFySAzhjD1tvp +gWgzgOvF8Z58QLiqbziPZ4pR7Q6dgZ49a65xAE6p8sv7JF92D0m2wQLkmj974wuvffJmcPAnKGl 0QUv9nBlSJd1cisSQGdnZ++BS1y0OXJmdoxmt8ABOteKvdUtcYDOn+L7yJ3Bop2n86G9N68lDtC5 kIwutcABOruR3qOWuOx6i7tD/L73U17g/2G/2nXt2G1o76/YpV0cYyRRj2kDXCBIm9MEQarAQALs c/NALvz7ISmS4kiz5XRpDMPE2aK4hqLIJZKUZcTj+Dp7/VpNOkceH2OhArWPz3nHsyci1tD3h9PR ZbJ1Fn4rah1tB7LAk5+eIjvwyp+uMaCL4YUqOyjYvFDE/0oBf3LzrPUX+o4xOPUNY4SsfUOwbEPG pYXD8zguBGrG7hYqtpbewn4LZOWScx+tRRDUq1r0o9l2RPAnq5lmCnf2ytXkooML8RK/SnOOjzBe WN8gV4C/JeLzjULE9OkL/QoA5KhZrgCqnBWx+HfrBWdu5cM2dMdz6C9Gv6AscycetMc/5151Fopc OmtZsLKeXMOZz2u8S5ZjTL/twhRhLBRjRvlottoXt8AYrFtE29ATS49lqacHt+TU0Fj6auwswTW6 VgIa/1EklzJ6fvojVtiBt4v9Vaf4JgexMjvFrSJ3fkp6FwmelXzuJxUamFCUkEqPqP0Wo3uUy6aD xFtyT+1x5QOwT2hyanDEUX2c/ScWFG0o1FH9bY7eoVw2TY5am09+fXBV9c16i9Yhy5WQhd4ie36H Ek8hab1YtyAccY/iNk2OQjS67LGAJE+QRBR/V49IFr1XcrFYUaIlUBSj6G/6FYrbNDtahcYlFvi7 57TVRZNa04jijktwblGKnVa4ayzIce9QLpuujuJFA80tJPvkgk18AavxxP0h8QC/j7OSemt+ug2t 0qxG8h7NG0zKSNz5hkOKgZWD2szCpb+CXfYvOu6+iGEMDMgzkvdg3mBRsi6XAcYjB8l7MLd/0QVq OKhjUbAaz0eX92DeYFKG3ih+dWCNYkbyDuyyf9HxYEI5Yt1+4rEj3Xt2NViUNAoe9PasA+Q9mjdY lJF0dZzzDNz1h1dgbv+k40+8Ud9nWJAfXd5hXfYvusofghGzs5yPLu/BvMGipPab20lD4+s8X1zn 1WBRRg5o0KBRhd+j+I2T8mNe6Jzyw01/+9+Ajschr7opsanqtKOs85OmftLUT5r6SVP/R5rasBNN J+Rc/y/zSe/1qIvmdlpm0HboDBptx2WKbUGmWJ1zcaHPubHajj5yxiLDSJCRM2bxMJJ3tJCkHY/S xMZoO/oAGIPMSVFGxKjjXJJ2MgRp0JcF+4qa2MIADdNnL14tfqPddDCJhR5dgmWxOaRztugdMg9J dOspx9L440I/uN5QPUd/zzOo7dAp1TBsjpWP2KCrXuTDNrCbOch4oOfIlDHuoBlkAtBI5Cwb+AO5 yHyqccwaB410yZJFy4LelpnYwgDtxxrflIObV5o15rZ+xR1M/NaT41tyjY1mrwVPY6Hh1WBp/EeF XGroKSxz0HPWTqZU/HsqtjjV2iUZ8HeKU7bYVKr5NJdaH9VcRvbzuZStZSo1KYJRaqlMVQFtqhve EJrdbv+to5/eg6u8aUHvwUxsodlJ6rW+bUHdMlqJdrQ81+u1PPWmXHn2AGs8R/lJxK3aXIH2YLgC 7eFy9SgLox7hklKjhCXp7LOuILtjlrjquqtAuBSDHt7KRcOT6xTRfE4RLYPK+yVYUS4LepFmYiV3 XnPDVX6Zqhgm5pBwuSpeilaONlKhZ7kjtGvNap24mk0X0rRS86XIJfu79094G5W6UPwnf4aTerED W8YC5O77x5gC8Hk/DuSM979+or/Qs/fvn/78+U9fAnxtn//x27+/vJWv+fPjl3/99vd/fnx5o+z8 /O3X/zx+/01U37785f0Pn355n19lQO+UXSkY8NAuGhrmVC81JBBg7zpncpYM9bIQuYEwizPTU0AQ lUOZjthjqwvxPDjR1m9cIV7T3QSN38JbOcB/K9V+Kwo1FmJ/BACvvlIk8KOcPoD3wMlxhp4tUGtn Adth/inG7PByZj4BNYX9P/uup26U5x8uLBNIPEt/OIbJ2ZNwwpDPVODJxOT0sVSmj8kRxsIZp4/F 6VvJjoRf/f64ZNOH+6X3qTFfFuyoy739MGkuaecdeK496PS9nIid3rCIYk/5JIxi6gOceppquxTU jRn5dMBQEz2sqO3hpVTmxozUMLIEa7csoIHHXJMC+tqKtL0EuvYgal5AOZomBXRjBklePlPHFZV9 FMGQWxtSp/FF4DJYIPmKTArqxozUdWQHMf96/bE+vBTUjRnA4TkB1WG9/hQeXhLq3ozUMLIDX6XV 1ZQfXgroayvSOuKBQkW6gJ4PLwV0Y4bf6yUp6kx9yIwK6eElo27NSJ2jV8c1AJnjaVJQN2akbi7o QF3BgsoBNSmoGzMAajeGOhGxLqgcUZOMujUjdTm8egUtHFCTAvrairSnCzo3UjNo5XiaFNCNGeBX HOtCuLKuoHI8TTLq1ozUjnUh3JF1ZUI1KagbM32AVH3ckXVj8jPJqFszUjvaRcJYA8A3L0IQX5uQ 1lEutZjrRXGHNKSAbswA6yFErw6Ln5W7ryEZdWtGahgRx8cSlovibFIhkBsbUjvKTeWGqWuAh5eC ujEDpC5HuahembpGPrhJRt2akdpxLs10K2h+eCmgr61I6yg3wQ1T10RlP6SAbsyAZhuXHemGqSvw JZlk1K0ZqR3lonpl6gp8dJOCujEjtaPcFG+YumY+u0lB3ZgBPrOOchPS+gJa+OgmGXRnRVrHuIm6 5xWUe3STAroxI7Wj3HTcMHWtxFBDCurGDLAlcpQbzxumZjJVwZBbG1I7vkX1StO1dTiVgroxo2HN 8W1sNzRdTz64SULdm5HacW6sK02Ti/2/wL3ePwbKri03HN244x9SQDdmgD27I1tUrxzduOUfklG3 ZqR2fBvzDUc37vmHFNSNGambCzfQmDijcoM+pKBuzABHoeiivjrK3fmQDPnahnSOamNaCbpxZz6k IL62Iq1j2hhvCLpxZz6kgG7MAEdLx7Qx3BB049Z8SEbdmpHaMS2qb0LKrfmQgroxI7Vj2njcEHQD viKTgroxgwyeasO5EnTjfn9IBt1ZkdYxLWpXgm7c7g8poBszUjumDUg1611xuz+koG7MIGdPtgEZ Z7qrH+wgteNVVK903HhgGJLd2ppBLp5XQ7mh41b4mk0y6taM1I5eQ76hY+4ZhxTQ11akdeyK6zMp /2AH5OqJFNdv+JfHmCHZq60ZqR2RhnTHv/zoDimoGzNSOyINceHfH+yA3Dxtru1wa/zGmGSfXtuQ LrvYBlpfIPmBMSmQGzNSny62yBllPuZ2B+TTE+R5R6snP1Bcqae8Ujsj0jp2PBdO3W8graPBdkee PNipX01dem0F5fAsWGfq3OpJ6diu3nDkyTNhd+uUyXBrRVrHdWVhyP0GKMEzXV6pcLuBtI7SkHbn 2thugBI9d+HybL3Rk9JxVJqJbasnpW8QVwbbboCSLp3gwl/7DaT1lLMQ1X4DaR3hHCsjbTdAAU8u H2OhBfLzOe94cm4+6B/noyoj3eYHZ1iNtvBkpjjY+yR4+PJ16qAO7+l6iUT59OSeTTdgoJ+ufaWd vHBIWWLHQL/dEHawhZtK2QkolnmpL+AfxR0KUvWp7RZaop7RmYwFAcWFXPxXWxIM9QsX+mfV8YY5 BP5ouADNHx4XQvThwfuQaEj8cEHiJRHGBf6tV7Dc4Fionf5xIfNH6iGHDTRs0kKUw3Y19NJDp/oF VI0FbeOF0pt3XOi/a683O2g9ZUPqN9Jk0rPQ0HEOH7ymkdDwNpgu4Axy8HnBLlExxkIw/kwXPzRT 1E9LJT2J5pqe1JJRY2HpqtGyhNZgasZrtK0k9D6saK5l1WvuKz3g/T9V3jVhscuvF1ZBteNaVK9t aTmIDoYU1I0ZpOY5GHN1bUvL0R5eMurWjNSOnLEklm6hBHoKhxTQ11akdZTNdbeCcjRNCujGDBIO JYdXr+1WYR9FMOTWhtSOieBcei0C4isyKagbM1LXkR3IQ229/lgfXgrqxgzg8PWF6rWBLYlGhyEJ dW9GanAPO9bbCpofXgroayvSthF0ZuoV9Hx4KaAbM/ye71DxQVj72gI05Q3JqFszUrvGFdVza4tI meNpUlA3ZqR2rSvATcdbMgfUpKBuzACib2khLU0eIXFETTLq1ozUrquFNPd+CFQ4oCYF9LUVaV2r C/y+zqA85g4poBszgORZF8KVdQWV42mSUbdmpPaNcbgjax5ThxTUjRkAXBrm446seSocklG3ZqT2 nfR5Q9Z88yIE8bUJaR3lIgHfMPV/2a+WHklqGHyfX9HHmcMOVUkqjyvSSogrfUGIE1oEqJuXWO3f x3Zsx5WkM9y4jFZrTdvxV44Tf7FpBmqSQRdu2K2ZnhvMfVcOTRLNV00S6tINzaYVh8eyb9YBCW+T CIZc+KDZUK6PE6ZOO/XtKhl14Ya9qaFcMI9MnRxtXCWhLt3QbDjXHyNTJ3dcrGTQx15oNZTrw4Sp k8eyb5JBF27YihvK9X7C1CnQIakk1KUbmg3lgnlk6hRo6yoZdeFmhxU0uwlTp4P2rpJRF244exjK 9UDrA2ikrask0JUXWg3jeuy2R9BysZJBF252ekPzNmHqlJChmmTUhVuAlshQrisTpiYyFUGQSx80 G74F80jTKVc4kYy6cMOZ0PCtyxOaToU2rhJR125oNpzr0kjTGGL9z3CP16PVkK2LE47O1PE3yaAL twA9uyFbMI8cnanlb5JQl25oNnzrjglHZ+r5m2TUhRuas0k3PD7DKWVq0Jtk1IVbgFHImayPgVJ3 3iRBPvZBm6Fa50eCztSZN8mIj73QapjWuQlBZ+rMm2TQhVuA0dIwrdsnBJ2pNW+SUJduaDZMC+ZJ Sqk1b5JRF25oNkzrtglB50BHpJJRF27hCJZq9zISdKZ+v0kCXXmh1TAtWEeCztTuN8mgCzc0G6bd gWrGs6J2v0lGXbiF47BkuwPjdGf1xgo0G14F80jHmQaGJimspVs4ouXVPU7oOEc6ZpWEunRDs6HX /ZjQMfWMTTLoYy+0GnYFfU/Kb6wIR7JECvoJ/9IY0yRFtXRDsyHS3c/4lx7dJhl14YZmQ6S7G/j3 jRXhyJY2x3Y4Z3pjVFJMj33Qdpjc7qgfIOmBUcmQCzc0F5Nb4IzYb3O5IhzFEmSZ0WqhB4oqtfAr tXJCq2HHMnDqegFaDQ3mGXnSYCdxZQnpsVeIm2XB1FPn0o5Gw3ZpwpGFZsIaVuHJcOmFVsN1cWDI 9YIQd8t0x0iFywVoNZQGtNvXxnJBiM5yF6h774UdjYajfE9sSzsabYM4MthyQYj+1AkO/LVegFZL OQNRrReg1RDONjLSckGIwZLLvSnyjnHe+hW3ejehuL5cjM3hYd7pgiWnihsRxUbBe4aDh68yBzZ4 N9NKeLxON2rZZAHk+Wa6V1xJio2rEhoG/G1msI08zFBKQYSoF89XBfwRzZ6CT/ZmG0X22DIal6Zg UFAc0X41e8aQuEBRPyuBZ7hCwW4NFCHbzYNidzY9cBycDc4fKDhfnGFQ0G85guEAmyJV9gfFQR9J G292x1kTFY43W82hVh4EVQ8gSS5wGSli7d1BUX+nWm660VR4ga8nknnQ09TgdjabvCyZkPTm0B1A 2XnjvUIPUTCaYlf69Kc45KZInHqVZCdy12SnehklF3pdJVt6oSWZcuMl21oSch5aNOeyuj19BxW3 QYMIXVl9Bbytslq0B3/CZUbIjFCzBy6Fv+FqEU9QPJei44QahXsM0pZUcvHmRQ49O0itc5gbU5uE CS4xnL8woGjvIWEahXsEYpf0YR5KURDV/URRXGKROxNlNZkJOO45jMwzHpv7m1Hobmcwp0VdqDHz 3dKMZmY6zWjht0YPHrrH3J3ZgNIuIB98U7hHIHZJF6a58TUVyfOF1prwXEaSUXA55WYOs+tua0ZV IbudwpwWnUOFxjXgrIOyTjse5s5NC9xTG0lPNr6WnREtEIhCJZzwUE6h2urOgt0FvMmvrfWLG77U kUp+RDqtH2zUo+I5KljAsFDOwazDYKTBAPOmaDSboJyjWYfBSEMucrGgJVcuVc7RrENn3Kmfhsun WJnamzxPml0+mGh6QcbXYcDTZOLncZ0dBiM8LR+w0Z5MmnM06zAYscWnS6tzwU4Twf4IzTp0xg2f YzC20Eo4LlXOwE7rB1uisIOZWCJmDeUczDoMxkBhexManWd5cJ5nh8HoKO5dsobVPUexCzvjvVdU Pnlz0S//DWi7bPyeq9Hh4fl69ff4zlHvHPXOUe8c9T9y1IqacCrBfqr+p7lEJs2ERXE3s2iSFliG 1cT9qo6ziWdRHXgTz6KHDIJ1PdQImTOPnsdWuztQJAIIuQ4pudTeNSReUHjmCxGooSrqVBhknC3c RfpU+/JRoR8RF1UIaK5zon414x2wYQ2Bp9dua5oKp7mpg6LmJrY5pK6IbRSq+Y28Nz2ByJ08t+3y W4ZRdZCmWyFlntWPysSrYaVYm3kNPKU6sunWUuEVsvm88QpJT95r4y75y3rqnOCy884GhRxSDt0x KoYctH5EFRKG3A0NtOB1t1uRz+pmZSuajnO25PpqPjU5knEpAT0SKZJzGd2YaTZ803IhXoW/T/VG Z3U/nfZwH/py05lUyo0Lsl26Oqq1iuuucTqXV0YePldCiV151ZwGr+fCCqcrXFd/59+Sc3VQhdfr 4s41rYoW1t4FftrXpBr3Mw9JKlsx1stkitGdcn9wIvR0Dk6Vnrwo9G6Ii6lG1xUjl+uhC3JXi1yc rRbD6YbLRlspdnVY02QKsSZSy0wVkWOSwzCl2in4PNVDfofuhpjK3fqwSk8g+bwvLdRWuTVOkxqu 1UZk9aqb4q3FYIp3Ox8Qp9vQaS24c0lS7X59fSqvJWFPCv/4z7BHQNrixSVsYMDlem8TwQ/P37/s 4TU///ECr//z579fPsTX4/ny8a/Pv/55f/ng/Gt6/vT7P5dvPrHp08uP12+fvrpeseO6/oxfjPK9 eIke4oeP7ZvD7NCnrj+h+PL0fHm5/vb08fr07wBDwCuzCmVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBv YmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9M YXN0Q2hhciAxMjEgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAzMzMg MCAwIDUwMCA1MDAgNTAwIDAgMCAwIDUwMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgNjY3IDAg MCA1NTYgMCA3MjIgMzMzIDM4OSAwIDAgMCA3MjIgMCA1NTYgMCAwIA0wIDYxMSA3MjIgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDQ0NCAwIDAgMCA0NDQgMzMzIDUwMCAwIDAgMCAwIDI3OCANMCA1MDAg NTAwIDUwMCAwIDMzMyAzODkgMjc4IDUwMCAwIDAgMCA1MDAgXSANL0VuY29kaW5nIC9XaW5BbnNp RW5jb2RpbmcgDS9CYXNlRm9udCAvVGltZXNOZXdSb21hblBTTVQgDS9Gb250RGVzY3JpcHRvciAx NSAwIFIgDT4+IA1lbmRvYmoNMTQgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1 ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjEgDS9XaWR0aHMgWyAyNzggMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAyNzggMCAwIDU1NiA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCAN MCAwIDAgMCAwIDAgNzIyIDcyMiA2NjcgNjExIDc3OCAwIDAgMCAwIDAgODMzIDAgNzc4IDAgMCA3 MjIgNjY3IA0wIDAgMCA5NDQgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDYxMSA1NTYgMCA1NTYgMzMz IDYxMSA2MTEgMjc4IDAgDTAgMjc4IDg4OSA2MTEgNjExIDYxMSA2MTEgMzg5IDU1NiAzMzMgNjEx IDU1NiA3NzggNTU2IDU1NiBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250 IC9BcmlhbC1Cb2xkSXRhbGljTVQgDS9Gb250RGVzY3JpcHRvciAxNiAwIFIgDT4+IA1lbmRvYmoN MTUgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA4OTEgDS9DYXBIZWln aHQgMCANL0Rlc2NlbnQgLTIxNiANL0ZsYWdzIDM0IA0vRm9udEJCb3ggWyAtNTY4IC0zMDcgMjAy OCAxMDA3IF0gDS9Gb250TmFtZSAvVGltZXNOZXdSb21hblBTTVQgDS9JdGFsaWNBbmdsZSAwIA0v U3RlbVYgMCANPj4gDWVuZG9iag0xNiAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0v QXNjZW50IDkwNSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgOTYgDS9Gb250 QkJveCBbIC01NjAgLTM3NiAxMTU3IDEwMzEgXSANL0ZvbnROYW1lIC9BcmlhbC1Cb2xkSXRhbGlj TVQgDS9JdGFsaWNBbmdsZSAtMTUgDS9TdGVtViAxMzMgDT4+IA1lbmRvYmoNMTcgMCBvYmoNPDwg DS9UeXBlIC9QYWdlcyANL0tpZHMgWyAyMSAwIFIgMSAwIFIgNCAwIFIgNyAwIFIgMTAgMCBSIF0g DS9Db3VudCA1IA0+PiANZW5kb2JqDTE4IDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChEOjIwMDEw NjI5MTM0NTU2KQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVyIDQuMCBmb3IgV2luZG93cykN L01vZERhdGUgKEQ6MjAwMTA2MjkxMzQ2MjQtMDcnMDAnKQ0+PiANZW5kb2JqDXhyZWYNMCAxOSAN MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAzNjY3IDAwMDAwIG4NCjAwMDAwMDM4MTggMDAwMDAg bg0KMDAwMDAwMzk4OSAwMDAwMCBuDQowMDAwMDA2NDI5IDAwMDAwIG4NCjAwMDAwMDY1ODAgMDAw MDAgbg0KMDAwMDAwNjczOCAwMDAwMCBuDQowMDAwMDI3ODQ3IDAwMDAwIG4NCjAwMDAwMjc5OTgg MDAwMDAgbg0KMDAwMDAyODE1NiAwMDAwMCBuDQowMDAwMDQzMjIwIDAwMDAwIG4NCjAwMDAwNDMz NzQgMDAwMDAgbg0KMDAwMDA0MzUzMyAwMDAwMCBuDQowMDAwMDcxMDE2IDAwMDAwIG4NCjAwMDAw NzE0MzkgMDAwMDAgbg0KMDAwMDA3MTg3NyAwMDAwMCBuDQowMDAwMDcyMDY4IDAwMDAwIG4NCjAw MDAwNzIyNjQgMDAwMDAgbg0KMDAwMDA3MjM1NSAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDE5 DS9JRFs8ZTY4Yzk4YmFmYTMzNzI5NTIwNDI1ZWYwOGQ0YTk1ZmY+PGU2OGM5OGJhZmEzMzcyOTUy MDQyNWVmMDhkNGE5NWZmPl0NPj4Nc3RhcnR4cmVmDTE3Mw0lJUVPRg0= ------_=_NextPart_000_01C100DD.BBB8D6F0-- From owner-ips@ece.cmu.edu Fri Jun 29 21:41:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00615 for ; Fri, 29 Jun 2001 21:41:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5TNleH16133 for ips-outgoing; Fri, 29 Jun 2001 19:47:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5TNlcg16127 for ; Fri, 29 Jun 2001 19:47:38 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id XAA27650; Fri, 29 Jun 2001 23:47:24 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 29 Jun 2001 23:47:24 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 16:47:22 -0700 Message-ID: <3677E033A5F3D211AC4000A0C96B53EB05C2EA39@FMSMSX94> From: "Herbert, Howard C" To: "'black_david@emc.com'" , ips@ece.cmu.edu Subject: iSCSI IPsec-Related Algorithm Proposal Date: Fri, 29 Jun 2001 16:47:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk David: Progress on completing the iSCSI draft RFCs is extending past the development deadlines necessary to allow 2002 product teams to complete their designs. One open issue relates to selecting the specific IPsec ESP integrity (mandatory to implement) and confidentiality (optional to implement) algorithms for use with iSCSI. Members of the working group have been focused until now on algorithms that would scale to 10 Gbit/sec. Even though progress has been made at identifying promising candidate algorithms (AES-based PMAC Mode for integrity and AES-based Counter Mode for confidentiality - see http://csrc.nist.gov/encryption/modes/), this work will not be completed in time for inclusion in 2002 products. As a result, I would like to propose to the iSCSI Working Group a two-phase strategy for selecting the specific IPsec ESP integrity and confidentiality algorithms for use with iSCSI. Since almost all 2002 products will be using 1 Gbit/sec interfaces, phase one products would standardize on already approved IPsec ESP algorithms that can be scaled to 1 Gbit/sec and phase two products (i.e., 2003) would standardize on algorithms that can be scaled to 10 Gbit/sec. Specifically, phase one products would use AES CBC MAC mode as the integrity algorithm and AES CBC mode as the confidentiality algorithm. This proposal means vendors only have to implement a single base-algorithm with slight mode variations in order to have a complete 1 Gbit solution (integrity and confidentiality). Adopting AES in phase one also establishes a foundation upon which to build phase two solutions (different modes of operation on the same base algorithm). While this proposal only addresses a small part of the total "iSCSI security" problem. It would allow silicon vendors to finalize a critical part of their 2002 designs. Thanks Howard C. Herbert Product Architect Intel Corporation LAN Access Division Phone: 480-554-3116 From owner-ips@ece.cmu.edu Fri Jun 29 21:48:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00665 for ; Fri, 29 Jun 2001 21:48:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f5U0SJ618469 for ips-outgoing; Fri, 29 Jun 2001 20:28:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f5U0SIg18465 for ; Fri, 29 Jun 2001 20:28:18 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 20:30:04 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E07097D@corpmx14.us.dg.com> From: Black_David@emc.com To: howard.c.herbert@intel.com, ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal Date: Fri, 29 Jun 2001 20:24:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk > Specifically, phase one products would use AES CBC MAC mode as the integrity > algorithm and AES CBC mode as the confidentiality algorithm. This proposal > means vendors only have to implement a single base-algorithm with slight > mode variations in order to have a complete 1 Gbit solution (integrity and > confidentiality). Adopting AES in phase one also establishes a foundation > upon which to build phase two solutions (different modes of operation on the > same base algorithm). What would you recommend as reference specifications for these algorithms, and specifically their use with ESP? There are no RFCs specifying this, and I haven't seen an Internet-Draft on the MAC (there is one on use of AES for confidentiality). My personal preference would be for something AES-based (perhaps using one of the new SHA hashes in an HMAC instead of the AES CBC MAC) rather than falling back to things like SHA-1 and 3DES. Meanwhile, we have another issue. As of the outcome of the Nashua meeting, the minimum (MUST implement) requirement for keying ESP was manual keying. That's not going to be sufficient because there will be situations in which iSCSI causes ESP's 32-bit sequence number to roll over, creating a vulnerability to replay attacks. This is going to require specification of a MUST implement rekeying algorithm. IKE or a subset is one possibility, and working out the details of SRP-based keying (and rekeying) of ESP is another. A somewhat drafty draft on the latter may appear prior to London assuming that I can find the "copious spare time" to get it written. Comments? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sat Jun 30 21:53:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28461 for ; Sat, 30 Jun 2001 21:53:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6108aa08258 for ips-outgoing; Sat, 30 Jun 2001 20:08:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6108Zg08253 for ; Sat, 30 Jun 2001 20:08:35 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id CAA241154 for ; Sun, 1 Jul 2001 02:08:28 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f6108MF117244 for ; Sun, 1 Jul 2001 02:08:28 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A7C.00008295 ; Sun, 1 Jul 2001 02:05:34 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Sun, 1 Jul 2001 02:40:36 +0300 Subject: RE: mailing list Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk No - I did not see it earlier - probably wwhen I was taken of the list... comments in text. Thanks, Julo "Ayman Ghanem" on 30-06-2001 23:45:13 Please respond to "Ayman Ghanem" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: mailing list Julian, I sent this to you last week. Not sure if you got it. Also, in the Task Management Response, I believe the MSB of the reserved field (bit 24) should be set to 1 like other PDUs going from the target side. +++ fixed +++ -Ayman ---------------------------------------------------------------------------- ------ Julian, I have the following comments on draft-6.90: 1- I am not sure if you saw this posting, but it is not clarified in 6.90 http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html 2- I would prefer, for this draft and any future drafts, that any new response codes added to be assigned new values and not values assigned earlier to still-existing return codes. This will help backward compatibility with earlier drafts. For example, Task Mgt Rsp, Reject, and logout have responses which existed in earlier drafts but are now given new codes. ++OK (for the future and if regularity does not require otherwise) +++ 3- Section 7.1, there is no reject response code for "Unsupported Replay". +++ yes there is - code 7 - i'll make wording clearer +++ 4- In sec. 4.1, version number 0x'01' should be 0x'02' +++ fixed ++++ 5- Sec. 2.16.5, no Additional Runs field in the SNACK PDU +++ fixed +++ 6- Bit-7 of byte 1 of the logout command should be set to 0, or as an F-bit to be consistent with text of section 2.2.2.4 +++ Logout is always single and last. That is why I set the F bit to 1 +++ 7- In section 2.16.1, "targets MUST support Status SNACK". However, in section 1.2.2.2, "To enable command recovery the target MAY maintain enough state information to enable data and status recovery after a connection failure". These seem to be inconsistent. Also, I could not see the scenario if the target can not support a Status SNACK request. If dropping the connection is the option, then I think it should be clarified. +++ the current text reads: An iSCSI target that does not support recovery within connection MAY discard status SNACK. If the target supports command recovery within session it MAY discard the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event indicating "Request Logout". ++++ -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Wednesday, June 27, 2001 8:29 AM > To: ips@ece.cmu.edu > Cc: bassoon@YOGI.PDL.CMU.EDU > Subject: mailing list > > > > > Dear colleagues, > > I do not receive mail from the list (since mid last week). > Please address mail that you think should reach me adding me explicitly > until the issue is fixed. > > Regards, > Julo > > > From owner-ips@ece.cmu.edu Sat Jun 30 21:53:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28472 for ; Sat, 30 Jun 2001 21:53:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f610jSY10118 for ips-outgoing; Sat, 30 Jun 2001 20:45:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f610jRg10114 for ; Sat, 30 Jun 2001 20:45:27 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id CAA223014; Sun, 1 Jul 2001 02:45:20 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f610jIF134374; Sun, 1 Jul 2001 02:45:18 +0200 Importance: Normal Subject: RE: iSCSI IPsec-Related Algorithm Proposal To: Black_David@emc.com Cc: ips@ece.cmu.edu, "howard.c.herbert" , "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 30 Jun 2001 19:12:43 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 01/07/2001 02:45:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think security issues go beyond the rekeying and I doubt that manual keying is an acceptable solution (not even as a starter) as it creates a management nightmare even in moderately sized installations and is barely supported in host systems (manually inserting keys AND SPIs). Howard is has a good point about schedules. and he is also pointing us towards a solution - select a minimum subset and get fast in place a keying mechanism that is both well understood and accepted. Julo Black_David@emc.com on 30-06-2001 03:24:54 Please respond to Black_David@emc.com To: howard.c.herbert@intel.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI IPsec-Related Algorithm Proposal > Specifically, phase one products would use AES CBC MAC mode as the integrity > algorithm and AES CBC mode as the confidentiality algorithm. This proposal > means vendors only have to implement a single base-algorithm with slight > mode variations in order to have a complete 1 Gbit solution (integrity and > confidentiality). Adopting AES in phase one also establishes a foundation > upon which to build phase two solutions (different modes of operation on the > same base algorithm). What would you recommend as reference specifications for these algorithms, and specifically their use with ESP? There are no RFCs specifying this, and I haven't seen an Internet-Draft on the MAC (there is one on use of AES for confidentiality). My personal preference would be for something AES-based (perhaps using one of the new SHA hashes in an HMAC instead of the AES CBC MAC) rather than falling back to things like SHA-1 and 3DES. Meanwhile, we have another issue. As of the outcome of the Nashua meeting, the minimum (MUST implement) requirement for keying ESP was manual keying. That's not going to be sufficient because there will be situations in which iSCSI causes ESP's 32-bit sequence number to roll over, creating a vulnerability to replay attacks. This is going to require specification of a MUST implement rekeying algorithm. IKE or a subset is one possibility, and working out the details of SRP-based keying (and rekeying) of ESP is another. A somewhat drafty draft on the latter may appear prior to London assuming that I can find the "copious spare time" to get it written. Comments? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Sat Jun 30 21:54:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28483 for ; Sat, 30 Jun 2001 21:54:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6108sh08272 for ips-outgoing; Sat, 30 Jun 2001 20:08:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6108qg08268 for ; Sat, 30 Jun 2001 20:08:52 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id CAA54726; Sun, 1 Jul 2001 02:08:45 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f6108jF116992; Sun, 1 Jul 2001 02:08:45 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A7C.00008210 ; Sun, 1 Jul 2001 02:05:32 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: Black_David@emc.com cc: ips@ece.cmu.edu, howard.c.herbert@intel.com, ips@ece.cmu.edu Message-ID: Date: Sat, 30 Jun 2001 19:12:43 +0300 Subject: RE: iSCSI IPsec-Related Algorithm Proposal Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk I think security issues go beyond the rekeying and I doubt that manual keying is an acceptable solution (not even as a starter) as it creates a management nightmare even in moderately sized installations and is barely supported in host systems (manually inserting keys AND SPIs). Howard is has a good point about schedules. and he is also pointing us towards a solution - select a minimum subset and get fast in place a keying mechanism that is both well understood and accepted. Julo Black_David@emc.com on 30-06-2001 03:24:54 Please respond to Black_David@emc.com To: howard.c.herbert@intel.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI IPsec-Related Algorithm Proposal > Specifically, phase one products would use AES CBC MAC mode as the integrity > algorithm and AES CBC mode as the confidentiality algorithm. This proposal > means vendors only have to implement a single base-algorithm with slight > mode variations in order to have a complete 1 Gbit solution (integrity and > confidentiality). Adopting AES in phase one also establishes a foundation > upon which to build phase two solutions (different modes of operation on the > same base algorithm). What would you recommend as reference specifications for these algorithms, and specifically their use with ESP? There are no RFCs specifying this, and I haven't seen an Internet-Draft on the MAC (there is one on use of AES for confidentiality). My personal preference would be for something AES-based (perhaps using one of the new SHA hashes in an HMAC instead of the AES CBC MAC) rather than falling back to things like SHA-1 and 3DES. Meanwhile, we have another issue. As of the outcome of the Nashua meeting, the minimum (MUST implement) requirement for keying ESP was manual keying. That's not going to be sufficient because there will be situations in which iSCSI causes ESP's 32-bit sequence number to roll over, creating a vulnerability to replay attacks. This is going to require specification of a MUST implement rekeying algorithm. IKE or a subset is one possibility, and working out the details of SRP-based keying (and rekeying) of ESP is another. A somewhat drafty draft on the latter may appear prior to London assuming that I can find the "copious spare time" to get it written. Comments? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------