From ips-bounces@ietf.org Tue Jun 05 13:26:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcnC-0007Zz-KH; Tue, 05 Jun 2007 13:26:02 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HvcnA-0007Zr-VM for ips-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 13:26:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcnA-0007Zj-Lu for ips@ietf.org; Tue, 05 Jun 2007 13:26:00 -0400 Received: from mail3.pillardata.com ([209.120.231.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvcn9-00038x-Ak for ips@ietf.org; Tue, 05 Jun 2007 13:26:00 -0400 Received: from coex02.trans.corp ([172.18.24.19]) by mail3.pillardata.com with ESMTP; 05 Jun 2007 10:25:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Jun 2007 11:26:02 -0600 Message-ID: <16236EEEF4D4264DA31C2E35E3607CFE094721E6@coex02.trans.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: target portal discovery using iSNS versus SendTargets Thread-Index: Acenlpnx40z22VqSS7CqYyOIOUEG6w== From: "Paul Hughes" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [Ips] target portal discovery using iSNS versus SendTargets X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1800423602==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1800423602== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A796.9783F1C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A796.9783F1C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am concerned that an iSCSI initiator that uses iSNS might not discover all portals of an iSCSI target in some situations. For example, if the target has registered for ESI monitoring of its portals and the iSNS server loses access to one portal the iSNS server will de-register the inaccessible portal. During this time if an SCSI initiator queries the iSNS database for the target's portal addresses it will see only those portals that are accessible to the iSNS server even though the initiator may have access to all portals. =20 On the other hand, if the iSCSI initiator used iSNS to obtain one target portal address and then issues SendTargets it would discover all of the portals. This of course assumes that an iSCSI target should report all of its portals in the SendTargets response regardless of whether the target has knowledge that one of its portals is inaccessible due to a portal hardware failure. =20 I guess what I'm trying to determine is whether iSCSI initiators are expected to query the iSNS database to detect the addition of target portals or whether they only query the iSNS database once during boot or driver initialization. Does anyone have any experience with some of the more popular iSCSI initiators to comment on this? =20 Thanks, Paul =20 ------_=_NextPart_001_01C7A796.9783F1C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am = concerned that=20 an iSCSI initiator that uses iSNS might not discover all portals of = an=20 iSCSI target in some situations.  For example, if the target=20 has registered for ESI monitoring of its portals and the iSNS=20 server loses access to one portal the iSNS=20 server will de-register the inaccessible portal.  = During=20 this time if an SCSI initiator queries the iSNS database for the = target's=20 portal addresses it will see only those portals that are accessible = to the=20 iSNS server even though the initiator may have access to all=20 portals.
 
On the = other hand,=20 if the iSCSI initiator used iSNS to obtain one target portal address and = then=20 issues SendTargets it would discover all of the portals.  This = of=20 course assumes that an iSCSI target should report all of its portals = in the=20 SendTargets response regardless of whether the target has knowledge that = one of=20 its portals is inaccessible due to a portal hardware=20 failure.
 
I = guess what I'm=20 trying to determine is whether iSCSI initiators are expected to query = the iSNS=20 database to detect the addition of target portals or whether they only = query the=20 iSNS database once during boot or driver initialization.  Does = anyone=20 have any experience with some of the more popular iSCSI initiators to = comment on=20 this?
 
Thanks,
Paul
 
------_=_NextPart_001_01C7A796.9783F1C0-- --===============1800423602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1800423602==-- From ips-bounces@ietf.org Tue Jun 05 15:19:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HveZ4-0006yu-2n; Tue, 05 Jun 2007 15:19:34 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HveZ1-0006vy-0Z for ips-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 15:19:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HveZ0-0006ve-MV for ips@ietf.org; Tue, 05 Jun 2007 15:19:30 -0400 Received: from web60711.mail.yahoo.com ([209.73.178.214]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HveYz-0002BO-7f for ips@ietf.org; Tue, 05 Jun 2007 15:19:30 -0400 Received: (qmail 25521 invoked by uid 60001); 5 Jun 2007 19:19:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=M8VdDjSGQyPJHJHbSmZFTzzRCryHq/bLc6fM4frjVKFN2KLeTEVUAjuT5lWeVXQD3QKs0oQvpiRNl+2YVrz8E3M/jSOfskTGXZeJd7Q9TrgWbyLjx0aCsph0t8R8nuSnzteI5Oa+NCYBjl0OOm3JVMcG2Wgl25pLiFSES/t6xM4=; X-YMail-OSG: wsGC_YcVM1mguqKhM6vQJM4WuppPDSZKU8f5KFOF4gBT9CWXPudmvmrWJGsp7wU.58g3836u3KPYwqQegrubQ6S0IQ2Zaneon9JJp8zN3yzMuUrFqWR3 Received: from [66.195.191.22] by web60711.mail.yahoo.com via HTTP; Tue, 05 Jun 2007 12:19:29 PDT X-Mailer: YahooMailRC/651.23.1 YahooMailWebService/0.7.41.14 Date: Tue, 5 Jun 2007 12:19:28 -0700 (PDT) From: Joe Souza Subject: Re: [Ips] target portal discovery using iSNS versus SendTargets To: Paul Hughes , ips@ietf.org MIME-Version: 1.0 Message-ID: <11440.17595.qm@web60711.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1980465521==" Errors-To: ips-bounces@ietf.org --===============1980465521== Content-Type: multipart/alternative; boundary="0-863702966-1181071168=:17595" --0-863702966-1181071168=:17595 Content-Type: text/plain; charset=ascii One question I have is that if the iSNS server is likely to lose access to a portal on an iSCSI target, isn't it also likely that an iSCSI initiator will also lose access to that same portal? In that case, the iSNS server would be behaving correctly to deregister the unreachable portal. Use of ESI by iSNS clients is optional. If you don't wish the iSNS server to depend on your target portal's accessibility via ESI, you could instead proactively transact with the iSNS server before your Registration Period has expired. A transaction received by the iSNS server from a registered iSNS client will serve to refresh that client's registration. You would of course need to repeatedly transact with the iSNS server at a time interval less than the client's Registration Period in order to maintain the client's registration in the database, unless you are using ESI instead (an ESI response received by an iSNS server from a registered iSNS client will also server to refresh that client's registration). Finally, it would be considered prudent for iSNS clients to register for SCNs to be notified whenever there are changes made to registered iSNS clients that the iSNS client is interested in. For example, an iSCSI client may wish to be notified whenever changes are made to iSCSI targets (which are registered with the iSNS server), and likewise, iSCSI targets may wish to be notified whenever changes are made to iSCSI clients (which are registered with the iSNS server). ----- Original Message ---- From: Paul Hughes To: ips@ietf.org Sent: Tuesday, June 5, 2007 10:26:02 AM Subject: [Ips] target portal discovery using iSNS versus SendTargets I am concerned that an iSCSI initiator that uses iSNS might not discover all portals of an iSCSI target in some situations. For example, if the target has registered for ESI monitoring of its portals and the iSNS server loses access to one portal the iSNS server will de-register the inaccessible portal. During this time if an SCSI initiator queries the iSNS database for the target's portal addresses it will see only those portals that are accessible to the iSNS server even though the initiator may have access to all portals. On the other hand, if the iSCSI initiator used iSNS to obtain one target portal address and then issues SendTargets it would discover all of the portals. This of course assumes that an iSCSI target should report all of its portals in the SendTargets response regardless of whether the target has knowledge that one of its portals is inaccessible due to a portal hardware failure. I guess what I'm trying to determine is whether iSCSI initiators are expected to query the iSNS database to detect the addition of target portals or whether they only query the iSNS database once during boot or driver initialization. Does anyone have any experience with some of the more popular iSCSI initiators to comment on this? Thanks, Paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --0-863702966-1181071168=:17595 Content-Type: text/html; charset=ascii
One question I have is that if the iSNS server is likely to lose access to a portal on an iSCSI target, isn't it also likely that an iSCSI initiator will also lose access to that same portal?  In that case, the iSNS server would be behaving correctly to deregister the unreachable portal.

Use of ESI by iSNS clients is optional.  If you don't wish the iSNS server to depend on your target portal's accessibility via ESI, you could instead proactively transact with the iSNS server before your Registration Period has expired.  A transaction received by the iSNS server from a registered iSNS client will serve to refresh that client's registration.  You would of course need to repeatedly transact with the iSNS server at a time interval less than the client's Registration Period in order to maintain the client's registration in the database, unless you are using ESI instead (an ESI response received by an iSNS server from a registered iSNS client will also server to refresh that client's registration).

Finally, it would be considered prudent for iSNS clients to register for SCNs to be notified whenever there are changes made to registered iSNS clients that the iSNS client is interested in.  For example, an iSCSI client may wish to be notified whenever changes are made to iSCSI targets (which are registered with the iSNS server), and likewise, iSCSI targets may wish to be notified whenever changes are made to iSCSI clients (which are registered with the iSNS server).

----- Original Message ----
From: Paul Hughes <phughes@pillardata.com>
To: ips@ietf.org
Sent: Tuesday, June 5, 2007 10:26:02 AM
Subject: [Ips] target portal discovery using iSNS versus SendTargets

I am concerned that an iSCSI initiator that uses iSNS might not discover all portals of an iSCSI target in some situations.  For example, if the target has registered for ESI monitoring of its portals and the iSNS server loses access to one portal the iSNS server will de-register the inaccessible portal.  During this time if an SCSI initiator queries the iSNS database for the target's portal addresses it will see only those portals that are accessible to the iSNS server even though the initiator may have access to all portals.
 
On the other hand, if the iSCSI initiator used iSNS to obtain one target portal address and then issues SendTargets it would discover all of the portals.  This of course assumes that an iSCSI target should report all of its portals in the SendTargets response regardless of whether the target has knowledge that one of its portals is inaccessible due to a portal hardware failure.
 
I guess what I'm trying to determine is whether iSCSI initiators are expected to query the iSNS database to detect the addition of target portals or whether they only query the iSNS database once during boot or driver initialization.  Does anyone have any experience with some of the more popular iSCSI initiators to comment on this?
 
Thanks,
Paul
 
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--0-863702966-1181071168=:17595-- --===============1980465521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1980465521==-- From ips-bounces@ietf.org Thu Jun 07 08:40:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHIK-0005vu-U6; Thu, 07 Jun 2007 08:40:52 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HwHIG-0005n2-9Z for ips-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 08:40:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHIF-0005mM-U8 for ips@ietf.org; Thu, 07 Jun 2007 08:40:47 -0400 Received: from web30104.mail.mud.yahoo.com ([209.191.69.36]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwHIF-000129-8c for ips@ietf.org; Thu, 07 Jun 2007 08:40:47 -0400 Received: (qmail 89020 invoked by uid 60001); 7 Jun 2007 12:40:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Bm7AqrJT6M+WDFjjGV3XhkWhK0ZKLyeO6zKsWhfp4LayzxLoJ7Iaf1H8cCTFFoRIabqhM8DGWtqUMD5iRrkRpDTrrDd1Qh2hiGDVnYmj/16UQytmNmqTSbNkacTnKoInK9DY41HMPbeQx3cUuUz6DtK6KB3vpt2BIH88hEuesBs=; X-YMail-OSG: jFzeA1gVM1kDTF..ewb3O3dw.nyTeu1Aoe3W.VPNln4XYI4.gPToVmO8hmowSkCMx2TYg4ZduS_Yj9LP5hu1q0YbDdnJ5Jxp0Sd0SfD5pdOVnIthl.egyfK5eRKPDQ-- Received: from [61.12.16.156] by web30104.mail.mud.yahoo.com via HTTP; Thu, 07 Jun 2007 05:40:46 PDT Date: Thu, 7 Jun 2007 05:40:46 -0700 (PDT) From: Parav Pandit To: ips@ietf.org MIME-Version: 1.0 Message-ID: <701777.88199.qm@web30104.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ips] iSCSI protocol - use of SendTargets X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0003113095==" Errors-To: ips-bounces@ietf.org --===============0003113095== Content-Type: multipart/alternative; boundary="0-1368142655-1181220046=:88199" Content-Transfer-Encoding: 8bit --0-1368142655-1181220046=:88199 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I am new to iSCSI protocol and gearing up. Is this the right mailing list to ask questions related to iSCSI protocol? if yes, 1. iSCSI target is identified by the network portal (IP + port). So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command? TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used. Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands? What is the expected information from the target in response to SendTargets command? Regards, Parav Pandit --------------------------------- It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. --0-1368142655-1181220046=:88199 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi,

I am new to iSCSI protocol and gearing up.
Is this the right mailing list to ask questions related to  iSCSI protocol?

if yes,

1.  iSCSI target is identified by the network portal (IP + port).
So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command?
TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used.
Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands?

What is the expected information from the target in response to SendTargets command?

Regards,
Parav Pandit

It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar. --0-1368142655-1181220046=:88199-- --===============0003113095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0003113095==-- From ips-bounces@ietf.org Thu Jun 07 09:17:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHs0-0000Pr-6Q; Thu, 07 Jun 2007 09:17:44 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HwHry-0000Pi-Sp for ips-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 09:17:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHry-0000PY-JH for ips@ietf.org; Thu, 07 Jun 2007 09:17:42 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwHrv-0007zD-M5 for ips@ietf.org; Thu, 07 Jun 2007 09:17:42 -0400 Received: by nz-out-0506.google.com with SMTP id z31so475057nzd for ; Thu, 07 Jun 2007 06:17:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qlzDJv/BNIkFbq/4XxQRFrYa3tqQWrRo6YVYQjmG5wDoanyoOW5daTetA6UyghTQaIxql5tS83VV1CPrBIePLDTEpvhgZT0Yxt5dwN9TeQxZB7niIJkRxOdsakCS22PWYqoFZLMpA5UA/540vsxTzNGHVXjv0NotumapNgPkzX0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=eAqhN/A1kcXo3HtQ9Y4rB4lQaNllY3JhXF3c8fzoKa1VeQB39kQw5rnxDtkIGjgBqwSo6oWdtLACwfipV70by0u9P/U6bGvklS/6YGFVhOypJsPDrLiE0kVgwh96Dm7tlYSrg7Ayfad4HcZ84FaX5UC81d+L7CfHneM5O+SziFM= Received: by 10.115.77.1 with SMTP id e1mr1516921wal.1181222258524; Thu, 07 Jun 2007 06:17:38 -0700 (PDT) Received: by 10.114.123.5 with HTTP; Thu, 7 Jun 2007 06:17:38 -0700 (PDT) Message-ID: <7d1c8ce10706070617o2db1eb74rbf5a2a26ff0fd0fa@mail.gmail.com> Date: Thu, 7 Jun 2007 09:17:38 -0400 From: GirisH To: "Parav Pandit" Subject: Re: [Ips] iSCSI protocol - use of SendTargets In-Reply-To: <701777.88199.qm@web30104.mail.mud.yahoo.com> MIME-Version: 1.0 References: <701777.88199.qm@web30104.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0066157739==" Errors-To: ips-bounces@ietf.org --===============0066157739== Content-Type: multipart/alternative; boundary="----=_Part_54541_29264435.1181222258470" ------=_Part_54541_29264435.1181222258470 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline There are two types of Sessions 1) Discovery Session -- This session contains the key as SENDTarget. No IO is allowed in this session.Only to get target Informaion 2) Normal Session : IO are allowed in FFP. The reply of SendTarget contains TargetName= Followed by zero or more address keys of the form: TargetAddress=[:], The hostname-or-ipaddress contains a domain name, IPv4 address, or IPv6 address, as specified for the TargetAddress key. iSCSI target is identified by [:], . Tag is very IMP. ---Girish On 6/7/07, Parav Pandit wrote: > > Hi, > > I am new to iSCSI protocol and gearing up. > Is this the right mailing list to ask questions related to iSCSI > protocol? > > if yes, > > 1. iSCSI target is identified by the network portal (IP + port). > So once the iSCSI target is identified by the network portal and Login to > it is successful, why do we need to ask for SendTargets command? > TargetName and TargetAddress returned are immaterial (because we already > know the target address to which we have logged-in), unless there are > multiple addresses for them and failover is required used. > Or it is used for communicating different TCP port on which initiators can > send TUR, Inquiry, Read, Write commands? > > What is the expected information from the target in response to > SendTargets command? > > Regards, > Parav Pandit > > ------------------------------ > It's here! Your new message! > Get new email alertswith the free Yahoo! > Toolbar. > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > On 6/7/07, Parav Pandit wrote: > > Hi, > > I am new to iSCSI protocol and gearing up. > Is this the right mailing list to ask questions related to iSCSI > protocol? > > if yes, > > 1. iSCSI target is identified by the network portal (IP + port). > So once the iSCSI target is identified by the network portal and Login to > it is successful, why do we need to ask for SendTargets command? > TargetName and TargetAddress returned are immaterial (because we already > know the target address to which we have logged-in), unless there are > multiple addresses for them and failover is required used. > Or it is used for communicating different TCP port on which initiators can > send TUR, Inquiry, Read, Write commands? > > What is the expected information from the target in response to > SendTargets command? > > Regards, > Parav Pandit > > ------------------------------ > It's here! Your new message! > Get new email alerts > with > the free Yahoo! Toolbar. > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > ------=_Part_54541_29264435.1181222258470 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
There are two types of Sessions
1) Discovery Session -- This session contains the key as SENDTarget. No IO is allowed in this session.Only to get target Informaion
2) Normal Session : IO are allowed in FFP. 
 
The reply of SendTarget contains
 
TargetName=<target-name-goes-here>

Followed by zero or more address keys of the form:

TargetAddress=<hostname-or-ipaddress>[:<tcp-port>],
<portal-group-tag>

The hostname-or-ipaddress contains a domain name, IPv4 address, or
IPv6 address, as specified for the TargetAddress key.

iSCSI target is identified by <hostname-or-ipaddress>[:<tcp-port>],
<portal-group-tag>. Tag is very IMP.


---Girish
 
On 6/7/07, Parav Pandit <paravpandit@yahoo.com> wrote:
Hi,

I am new to iSCSI protocol and gearing up.
Is this the right mailing list to ask questions related to  iSCSI protocol?

if yes,

1.  iSCSI target is identified by the network portal (IP + port).
So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command?
TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used.
Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands?

What is the expected information from the target in response to SendTargets command?

Regards,
Parav Pandit

It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.


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


 
 
On 6/7/07, Parav Pandit <paravpandit@yahoo.com > wrote:
Hi,

I am new to iSCSI protocol and gearing up.
Is this the right mailing list to ask questions related to  iSCSI protocol?

if yes,

1.  iSCSI target is identified by the network portal (IP + port).
So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command?
TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used.
Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands?

What is the expected information from the target in response to SendTargets command?

Regards,
Parav Pandit

It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.


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


------=_Part_54541_29264435.1181222258470-- --===============0066157739== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0066157739==-- From ips-bounces@ietf.org Thu Jun 07 10:51:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJL2-0004JE-S4; Thu, 07 Jun 2007 10:51:48 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HwJL1-0004J6-M3 for ips-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 10:51:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJL1-0004Iy-C8 for ips@ietf.org; Thu, 07 Jun 2007 10:51:47 -0400 Received: from mail1.pillardata.com ([63.251.178.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJL0-0002sr-MC for ips@ietf.org; Thu, 07 Jun 2007 10:51:47 -0400 Received: from coex02.trans.corp ([172.18.24.19]) by mail1.pillardata.com with ESMTP; 07 Jun 2007 08:51:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] target portal discovery using iSNS versus SendTargets Date: Thu, 7 Jun 2007 08:51:52 -0600 Message-ID: <16236EEEF4D4264DA31C2E35E3607CFE09472613@coex02.trans.corp> In-Reply-To: <11440.17595.qm@web60711.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] target portal discovery using iSNS versus SendTargets Thread-Index: AcenpsCx1Ur3VJqURTitSPHvakKqoQBakaAg References: <11440.17595.qm@web60711.mail.yahoo.com> From: "Paul Hughes" To: "Joe Souza" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1128029218==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1128029218== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A913.633189E5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A913.633189E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Joe. =20 Your comment about the initiator being prudent and registering for SCNs makes sense. I assume that an initiator that uses iSNS to discover targets will register for target-related SCNs. =20 By the way, what is the preferred method for a target to re-register a portal that has been de-registered by the server due to ESI failures? I was thinking the target could periodically send a DevAttrReg message from the portal that has lost access to the server until the registration succeeds. This DevAttrReg message would contain only the inaccessible portal's attributes and have the replace flag set to false. This seems to be more reasonable than having some other target portal re-register the inaccessible portal only to have it de-registered again when ESI fails (assuming that access has not been restored). =20 Thanks, Paul =20 ________________________________ From: Joe Souza [mailto:jsouza@yahoo.com]=20 Sent: Tuesday, June 05, 2007 1:19 PM To: Paul Hughes; ips@ietf.org Subject: Re: [Ips] target portal discovery using iSNS versus SendTargets One question I have is that if the iSNS server is likely to lose access to a portal on an iSCSI target, isn't it also likely that an iSCSI initiator will also lose access to that same portal? In that case, the iSNS server would be behaving correctly to deregister the unreachable portal. Use of ESI by iSNS clients is optional. If you don't wish the iSNS server to depend on your target portal's accessibility via ESI, you could instead proactively transact with the iSNS server before your Registration Period has expired. A transaction received by the iSNS server from a registered iSNS client will serve to refresh that client's registration. You would of course need to repeatedly transact with the iSNS server at a time interval less than the client's Registration Period in order to maintain the client's registration in the database, unless you are using ESI instead (an ESI response received by an iSNS server from a registered iSNS client will also server to refresh that client's registration). Finally, it would be considered prudent for iSNS clients to register for SCNs to be notified whenever there are changes made to registered iSNS clients that the iSNS client is interested in. For example, an iSCSI client may wish to be notified whenever changes are made to iSCSI targets (which are registered with the iSNS server), and likewise, iSCSI targets may wish to be notified whenever changes are made to iSCSI clients (which are registered with the iSNS server). ----- Original Message ---- From: Paul Hughes To: ips@ietf.org Sent: Tuesday, June 5, 2007 10:26:02 AM Subject: [Ips] target portal discovery using iSNS versus SendTargets I am concerned that an iSCSI initiator that uses iSNS might not discover all portals of an iSCSI target in some situations. For example, if the target has registered for ESI monitoring of its portals and the iSNS server loses access to one portal the iSNS server will de-register the inaccessible portal. During this time if an SCSI initiator queries the iSNS database for the target's portal addresses it will see only those portals that are accessible to the iSNS server even though the initiator may have access to all portals. =20 On the other hand, if the iSCSI initiator used iSNS to obtain one target portal address and then issues SendTargets it would discover all of the portals. This of course assumes that an iSCSI target should report all of its portals in the SendTargets response regardless of whether the target has knowledge that one of its portals is inaccessible due to a portal hardware failure. =20 I guess what I'm trying to determine is whether iSCSI initiators are expected to query the iSNS database to detect the addition of target portals or whether they only query the iSNS database once during boot or driver initialization. Does anyone have any experience with some of the more popular iSCSI initiators to comment on this? =20 Thanks, Paul =20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------_=_NextPart_001_01C7A913.633189E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks Joe.
 
Your comment about the initiator being prudent = and=20 registering for SCNs makes sense.  I assume that an initiator = that=20 uses iSNS to discover targets will register for=20 target-related SCNs.
 
By the way, what is the preferred method = for a=20 target to re-register a portal that has been de-registered by the server = due=20 to ESI failures?  I was thinking the target = could periodically=20 send a DevAttrReg message from the portal that has lost access to the=20 server until the registration succeeds.  This DevAttrReg=20 message would contain only the=20 inaccessible portal's attributes and have the replace flag set = to=20 false.  This seems to be more reasonable than having some other = target=20 portal re-register the inaccessible portal only to have it de-registered = again=20 when ESI fails (assuming that access has not been=20 restored).
 
Thanks,
Paul
 

From: Joe Souza = [mailto:jsouza@yahoo.com]=20
Sent: Tuesday, June 05, 2007 1:19 PM
To: Paul = Hughes;=20 ips@ietf.org
Subject: Re: [Ips] target portal discovery using = iSNS=20 versus SendTargets

One=20 question I have is that if the iSNS server is likely to lose access to a = portal=20 on an iSCSI target, isn't it also likely that an iSCSI initiator will = also lose=20 access to that same portal?  In that case, the iSNS server would be = behaving correctly to deregister the unreachable portal.

Use of = ESI by=20 iSNS clients is optional.  If you don't wish the iSNS server to = depend on=20 your target portal's accessibility via ESI, you could instead = proactively=20 transact with the iSNS server before your Registration Period has = expired. =20 A transaction received by the iSNS server from a registered iSNS client = will=20 serve to refresh that client's registration.  You would of course = need to=20 repeatedly transact with the iSNS server at a time interval less than = the=20 client's Registration Period in order to maintain the client's = registration in=20 the database, unless you are using ESI instead (an ESI response received = by an=20 iSNS server from a registered iSNS client will also server to refresh = that=20 client's registration).

Finally, it would be considered prudent = for iSNS=20 clients to register for SCNs to be notified whenever there are changes = made to=20 registered iSNS clients that the iSNS client is interested in.  For = example, an iSCSI client may wish to be notified whenever changes are = made to=20 iSCSI targets (which are registered with the iSNS server), and likewise, = iSCSI=20 targets may wish to be notified whenever changes are made to iSCSI = clients=20 (which are registered with the iSNS server).

-----=20 Original Message ----
From: Paul Hughes = <phughes@pillardata.com>
To:=20 ips@ietf.org
Sent: Tuesday, June 5, 2007 10:26:02 AM
Subject: = [Ips] target=20 portal discovery using iSNS versus SendTargets

I am = concerned that=20 an iSCSI initiator that uses iSNS might not discover all portals of = an=20 iSCSI target in some situations.  For example, if the target=20 has registered for ESI monitoring of its portals and the iSNS=20 server loses access to one portal the iSNS=20 server will de-register the inaccessible portal.  = During=20 this time if an SCSI initiator queries the iSNS database for the = target's=20 portal addresses it will see only those portals that are accessible = to the=20 iSNS server even though the initiator may have access to all=20 portals.
 
On the = other hand,=20 if the iSCSI initiator used iSNS to obtain one target portal address and = then=20 issues SendTargets it would discover all of the portals.  This = of=20 course assumes that an iSCSI target should report all of its portals = in the=20 SendTargets response regardless of whether the target has knowledge that = one of=20 its portals is inaccessible due to a portal hardware=20 failure.
 
I = guess what I'm=20 trying to determine is whether iSCSI initiators are expected to query = the iSNS=20 database to detect the addition of target portals or whether they only = query the=20 iSNS database once during boot or driver initialization.  Does = anyone=20 have any experience with some of the more popular iSCSI initiators to = comment on=20 this?
 
Thanks,
Paul
 
_______________________________________________
Ips mailing=20 list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
<= /DIV>
------_=_NextPart_001_01C7A913.633189E5-- --===============1128029218== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1128029218==-- From ips-bounces@ietf.org Thu Jun 07 17:59:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQ0V-0000Pu-SY; Thu, 07 Jun 2007 17:59:03 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HwQ0U-0000KI-Nk for ips-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 17:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQ0U-0000IK-DJ for ips@ietf.org; Thu, 07 Jun 2007 17:59:02 -0400 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwQ0S-0006cA-Vi for ips@ietf.org; Thu, 07 Jun 2007 17:59:02 -0400 Received: from aime2k302.adaptec.com (aime2k302.adaptec.com [10.25.8.48]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id EF85317058C; Thu, 7 Jun 2007 14:58:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] iSCSI protocol - use of SendTargets Date: Thu, 7 Jun 2007 14:58:57 -0700 Message-ID: <368FBF3D8437A748BA8222526BF9309901DE70E6@aime2k302.adaptec.com> In-Reply-To: <701777.88199.qm@web30104.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI protocol - use of SendTargets Thread-Index: AcepAT73x0jns+bhRTqWgeeTDHdPHQATHy5w References: <701777.88199.qm@web30104.mail.mud.yahoo.com> From: "Sandars, Ken" To: "Parav Pandit" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0638776631==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0638776631== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A94F.0D8423C6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A94F.0D8423C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Parav, =20 Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720.=20 =20 In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions. =20 The specifics of the SendTargets command are in Appendix D. =20 HTH Ken ________________________________ From: Parav Pandit [mailto:paravpandit@yahoo.com]=20 Sent: Thursday, 7 June 2007 22:41 To: ips@ietf.org Subject: [Ips] iSCSI protocol - use of SendTargets Hi, I am new to iSCSI protocol and gearing up. Is this the right mailing list to ask questions related to iSCSI protocol? if yes, 1. iSCSI target is identified by the network portal (IP + port). So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command? TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used. Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands? What is the expected information from the target in response to SendTargets command? Regards, Parav Pandit ________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. =20 ------_=_NextPart_001_01C7A94F.0D8423C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Parav,
 
Before any author shamelessly plugs = their iSCSI=20 publications, I suggest you have a quick re-read of RFC3720.=20
 
In particular, section 3.4 pages 37-40 cover = some=20 really important concepts that I think will help your understanding. = Then jump=20 to the start of section 3, page 17 for more concepts and=20 definitions.
 
The specifics of the SendTargets command are = in=20 Appendix D.
 
HTH
Ken

From: Parav Pandit=20 [mailto:paravpandit@yahoo.com]
Sent: Thursday, 7 June 2007=20 22:41
To: ips@ietf.org
Subject: [Ips] iSCSI protocol = - use=20 of SendTargets

Hi,

I am new to iSCSI protocol and gearing up.
Is = this the=20 right mailing list to ask questions related to  iSCSI = protocol?

if=20 yes,

1.  iSCSI target is identified by the network portal = (IP +=20 port).
So once the iSCSI target is identified by the network portal = and Login=20 to it is successful, why do we need to ask for SendTargets=20 command?
TargetName and TargetAddress returned are immaterial = (because we=20 already know the target address to which we have logged-in), unless = there are=20 multiple addresses for them and failover is required used.
Or it is = used for=20 communicating different TCP port on which initiators can send TUR, = Inquiry,=20 Read, Write commands?

What is the expected information from the = target in=20 response to SendTargets command?

Regards,
Parav Pandit

It's here! Your new message!
Get new=20 email alerts with the free Yahoo!=20 Toolbar. ------_=_NextPart_001_01C7A94F.0D8423C6-- --===============0638776631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0638776631==-- From ips-bounces@ietf.org Thu Jun 07 19:27:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwROB-0002OV-K9; Thu, 07 Jun 2007 19:27:35 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HwRO9-0002OQ-Ns for ips-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 19:27:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRO8-0002OH-Sk for ips@ietf.org; Thu, 07 Jun 2007 19:27:33 -0400 Received: from web60721.mail.yahoo.com ([209.73.178.209]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwRO7-0001sR-6I for ips@ietf.org; Thu, 07 Jun 2007 19:27:32 -0400 Received: (qmail 28710 invoked by uid 60001); 7 Jun 2007 23:27:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=z+MOJM8wmQWuEhxJz7Z5rQQqB2Ok2HewJGAL7BM0akVL4p0g6SbRH7miqD+muG359YZIj+qBQEzjfrPrGxsC4KvquA7EvmbGm+afMLXxbXmYGsmXbcKUnbq0shf2cHWss7lCuvNsGwU1GtHmzYG+tRzSkHvnbCz8LqFMpJPhq+M=; X-YMail-OSG: GzJh_NkVM1mwyKjc.By6aaa42uC1AMHf2jK3LalW6_Py9.5Cwm9jLYlueMnP.xy5qlBmWXhXa41JrjPuQdoqEYWH_EN_9E81mD1tFu_wKyjTnJWB_pha Received: from [66.195.191.22] by web60721.mail.yahoo.com via HTTP; Thu, 07 Jun 2007 16:27:30 PDT X-Mailer: YahooMailRC/651.23.1 YahooMailWebService/0.7.41.14 Date: Thu, 7 Jun 2007 16:27:30 -0700 (PDT) From: Joe Souza Subject: Re: [Ips] target portal discovery using iSNS versus SendTargets To: Paul Hughes , ips@ietf.org MIME-Version: 1.0 Message-ID: <953098.28518.qm@web60721.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1416262375==" Errors-To: ips-bounces@ietf.org --===============1416262375== Content-Type: multipart/alternative; boundary="0-2088717974-1181258850=:28518" --0-2088717974-1181258850=:28518 Content-Type: text/plain; charset=ascii Hi Paul, I see one flaw with your proposed method. As you know, if an iSNS server does not receive a response to a certain number of ESI requests, that ESI-registered Portal will be deregistered from the iSNS database. If, however, that Portal was the last remaining Portal in a given Entity (or i.e. the only Portal in that Entity), then the entire Entity will be deregistered. In that case, you would want to specify more than just the affected Portal's attributes in the DevAttrReg message, as the other objects and related attributes of that Entity may have already been deregistered from the iSNS server. A better approach, if your ESI-registered Portal has not received an ESI request from the iSNS server in a time period greater than the ESI Interval (or has not been able to successfully respond to such requests), would be to reissue the complete registration request for the entire Entity. Of course, if you know that you have at least one additional ESI-registered Portal in that Entity that has been receiving and responding to ESI requests on a regular basis, then you can assume that the registration for the Entity is still active, and then your approach of reregistering just the Portal in that Entity (specifying the EID as the registration key) should work for you. -Joe ----- Original Message ---- From: Paul Hughes To: Joe Souza ; ips@ietf.org Sent: Thursday, June 7, 2007 7:51:52 AM Subject: RE: [Ips] target portal discovery using iSNS versus SendTargets DIV { MARGIN:0px;} Thanks Joe. Your comment about the initiator being prudent and registering for SCNs makes sense. I assume that an initiator that uses iSNS to discover targets will register for target-related SCNs. By the way, what is the preferred method for a target to re-register a portal that has been de-registered by the server due to ESI failures? I was thinking the target could periodically send a DevAttrReg message from the portal that has lost access to the server until the registration succeeds. This DevAttrReg message would contain only the inaccessible portal's attributes and have the replace flag set to false. This seems to be more reasonable than having some other target portal re-register the inaccessible portal only to have it de-registered again when ESI fails (assuming that access has not been restored). Thanks, Paul From: Joe Souza [mailto:jsouza@yahoo.com] Sent: Tuesday, June 05, 2007 1:19 PM To: Paul Hughes; ips@ietf.org Subject: Re: [Ips] target portal discovery using iSNS versus SendTargets One question I have is that if the iSNS server is likely to lose access to a portal on an iSCSI target, isn't it also likely that an iSCSI initiator will also lose access to that same portal? In that case, the iSNS server would be behaving correctly to deregister the unreachable portal. Use of ESI by iSNS clients is optional. If you don't wish the iSNS server to depend on your target portal's accessibility via ESI, you could instead proactively transact with the iSNS server before your Registration Period has expired. A transaction received by the iSNS server from a registered iSNS client will serve to refresh that client's registration. You would of course need to repeatedly transact with the iSNS server at a time interval less than the client's Registration Period in order to maintain the client's registration in the database, unless you are using ESI instead (an ESI response received by an iSNS server from a registered iSNS client will also server to refresh that client's registration). Finally, it would be considered prudent for iSNS clients to register for SCNs to be notified whenever there are changes made to registered iSNS clients that the iSNS client is interested in. For example, an iSCSI client may wish to be notified whenever changes are made to iSCSI targets (which are registered with the iSNS server), and likewise, iSCSI targets may wish to be notified whenever changes are made to iSCSI clients (which are registered with the iSNS server). ----- Original Message ---- From: Paul Hughes To: ips@ietf.org Sent: Tuesday, June 5, 2007 10:26:02 AM Subject: [Ips] target portal discovery using iSNS versus SendTargets I am concerned that an iSCSI initiator that uses iSNS might not discover all portals of an iSCSI target in some situations. For example, if the target has registered for ESI monitoring of its portals and the iSNS server loses access to one portal the iSNS server will de-register the inaccessible portal. During this time if an SCSI initiator queries the iSNS database for the target's portal addresses it will see only those portals that are accessible to the iSNS server even though the initiator may have access to all portals. On the other hand, if the iSCSI initiator used iSNS to obtain one target portal address and then issues SendTargets it would discover all of the portals. This of course assumes that an iSCSI target should report all of its portals in the SendTargets response regardless of whether the target has knowledge that one of its portals is inaccessible due to a portal hardware failure. I guess what I'm trying to determine is whether iSCSI initiators are expected to query the iSNS database to detect the addition of target portals or whether they only query the iSNS database once during boot or driver initialization. Does anyone have any experience with some of the more popular iSCSI initiators to comment on this? Thanks, Paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --0-2088717974-1181258850=:28518 Content-Type: text/html; charset=ascii
Hi Paul,

I see one flaw with your proposed method.  As you know, if an iSNS server does not receive a response to a certain number of ESI requests, that ESI-registered Portal will be deregistered from the iSNS database.  If, however, that Portal was the last remaining Portal in a given Entity (or i.e. the only Portal in that Entity), then the entire Entity will be deregistered.  In that case, you would want to specify more than just the affected Portal's attributes in the DevAttrReg message, as the other objects and related attributes of that Entity may have already been deregistered from the iSNS server.  A better approach, if your ESI-registered Portal has not received an ESI request from the iSNS server in a time period greater than the ESI Interval (or has not been able to successfully respond to such requests), would be to reissue the complete registration request for the entire Entity.  Of course, if you know that you have at least one additional ESI-registered Portal in that Entity that has been receiving and responding to ESI requests on a regular basis, then you can assume that the registration for the Entity is still active, and then your approach of reregistering just the Portal in that Entity (specifying the EID as the registration key) should work for you.

-Joe

----- Original Message ----
From: Paul Hughes <phughes@pillardata.com>
To: Joe Souza <jsouza@yahoo.com>; ips@ietf.org
Sent: Thursday, June 7, 2007 7:51:52 AM
Subject: RE: [Ips] target portal discovery using iSNS versus SendTargets

Thanks Joe.
 
Your comment about the initiator being prudent and registering for SCNs makes sense.  I assume that an initiator that uses iSNS to discover targets will register for target-related SCNs.
 
By the way, what is the preferred method for a target to re-register a portal that has been de-registered by the server due to ESI failures?  I was thinking the target could periodically send a DevAttrReg message from the portal that has lost access to the server until the registration succeeds.  This DevAttrReg message would contain only the inaccessible portal's attributes and have the replace flag set to false.  This seems to be more reasonable than having some other target portal re-register the inaccessible portal only to have it de-registered again when ESI fails (assuming that access has not been restored).
 
Thanks,
Paul
 

From: Joe Souza [mailto:jsouza@yahoo.com]
Sent: Tuesday, June 05, 2007 1:19 PM
To: Paul Hughes; ips@ietf.org
Subject: Re: [Ips] target portal discovery using iSNS versus SendTargets

One question I have is that if the iSNS server is likely to lose access to a portal on an iSCSI target, isn't it also likely that an iSCSI initiator will also lose access to that same portal?  In that case, the iSNS server would be behaving correctly to deregister the unreachable portal.

Use of ESI by iSNS clients is optional.  If you don't wish the iSNS server to depend on your target portal's accessibility via ESI, you could instead proactively transact with the iSNS server before your Registration Period has expired.  A transaction received by the iSNS server from a registered iSNS client will serve to refresh that client's registration.  You would of course need to repeatedly transact with the iSNS server at a time interval less than the client's Registration Period in order to maintain the client's registration in the database, unless you are using ESI instead (an ESI response received by an iSNS server from a registered iSNS client will also server to refresh that client's registration).

Finally, it would be considered prudent for iSNS clients to register for SCNs to be notified whenever there are changes made to registered iSNS clients that the iSNS client is interested in.  For example, an iSCSI client may wish to be notified whenever changes are made to iSCSI targets (which are registered with the iSNS server), and likewise, iSCSI targets may wish to be notified whenever changes are made to iSCSI clients (which are registered with the iSNS server).

----- Original Message ----
From: Paul Hughes <phughes@pillardata.com>
To: ips@ietf.org
Sent: Tuesday, June 5, 2007 10:26:02 AM
Subject: [Ips] target portal discovery using iSNS versus SendTargets

I am concerned that an iSCSI initiator that uses iSNS might not discover all portals of an iSCSI target in some situations.  For example, if the target has registered for ESI monitoring of its portals and the iSNS server loses access to one portal the iSNS server will de-register the inaccessible portal.  During this time if an SCSI initiator queries the iSNS database for the target's portal addresses it will see only those portals that are accessible to the iSNS server even though the initiator may have access to all portals.
 
On the other hand, if the iSCSI initiator used iSNS to obtain one target portal address and then issues SendTargets it would discover all of the portals.  This of course assumes that an iSCSI target should report all of its portals in the SendTargets response regardless of whether the target has knowledge that one of its portals is inaccessible due to a portal hardware failure.
 
I guess what I'm trying to determine is whether iSCSI initiators are expected to query the iSNS database to detect the addition of target portals or whether they only query the iSNS database once during boot or driver initialization.  Does anyone have any experience with some of the more popular iSCSI initiators to comment on this?
 
Thanks,
Paul
 
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

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

--0-2088717974-1181258850=:28518-- --===============1416262375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1416262375==-- From ips-bounces@ietf.org Wed Jun 13 11:23:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUh0-0002Z9-Lw; Wed, 13 Jun 2007 11:23:30 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HyUgz-0002Z4-8M for ips-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 11:23:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUgy-0002Yv-V5 for ips@ietf.org; Wed, 13 Jun 2007 11:23:28 -0400 Received: from mail3.pillardata.com ([209.120.231.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUgv-0003FC-HV for ips@ietf.org; Wed, 13 Jun 2007 11:23:28 -0400 Received: from coex02.trans.corp ([172.18.24.19]) by mail3.pillardata.com with ESMTP; 13 Jun 2007 08:22:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Jun 2007 09:22:32 -0600 Message-ID: <16236EEEF4D4264DA31C2E35E3607CFE095A19F8@coex02.trans.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSNS database unique ID Thread-Index: Acetzqu47/FkwxuLRseDSNHj6vssRA== From: "Paul Hughes" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [Ips] iSNS database unique ID X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0936000023==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0936000023== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ADCE.AAFADF01" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADCE.AAFADF01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am developing an iSNS client for an iSCSI target that supports multiple portals. It's possible that the target portals could be connected to different networks so I'd like to determine if each target portal has access to the same iSNS database. Section 6.9.1 of RFC 4171 (iSNS) states that an iSNS client can query for the iSNS Server Vendor OUI, but I assume that wouldn't be a unique value for the iSNS database. Is there some other value an iSNS client can query that would be unique to the iSNS database? =20 If not, then I could have one portal register the target's Network Entity and then have each portal query the target's registration to determine if they can retrieve the target's Network Entity or not. Is there a better method? =20 Thanks, Paul =20 ------_=_NextPart_001_01C7ADCE.AAFADF01 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am = developing an=20 iSNS client for an iSCSI target that supports multiple portals.  = It's=20 possible that the target portals could be connected to different = networks=20 so I'd like to determine if each target portal has access = to the same=20 iSNS database.  Section 6.9.1 of RFC 4171 (iSNS) states that an = iSNS client=20 can query for the iSNS Server Vendor OUI, but I assume that = wouldn't be a=20 unique value for the iSNS database.  Is there some other = value an=20 iSNS client can query that would be unique to the iSNS=20 database?
 
If = not, then I could=20 have one portal register the target's Network Entity and then=20 have each portal query the target's registration to determine = if=20 they can retrieve the target's Network Entity or = not. =20 Is there a better method?
 
Thanks,
Paul
 
------_=_NextPart_001_01C7ADCE.AAFADF01-- --===============0936000023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0936000023==-- From ips-bounces@ietf.org Wed Jun 13 16:00:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyZ0t-0000GR-4A; Wed, 13 Jun 2007 16:00:19 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1HyZ0s-0000G3-JS for ips-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 16:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyZ0s-0000Fv-9w for ips@ietf.org; Wed, 13 Jun 2007 16:00:18 -0400 Received: from web60724.mail.yahoo.com ([209.73.178.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HyZ0r-0005Qf-RJ for ips@ietf.org; Wed, 13 Jun 2007 16:00:18 -0400 Received: (qmail 36258 invoked by uid 60001); 13 Jun 2007 20:00:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=COa8dzP8a7je4X25olyv9EkF+P76cl7YJRjQN9IjF8e1sKBL5KzEnpSVXNRMDhH+zYayVZ86wQ0/WioYZgx6nAboDmRqBiayuaAKqXO2L0rD3TfEuHaBcGBQWe4nMAs7YrxU8dSvF9/Lra87V5KUBmIWfF/89hzJriSIWKZDsBM=; X-YMail-OSG: 0JevVwUVM1n2kMhGOI3ouAKgHjiQ.s8Tv9b3c0G1uz1bq6.Q0oKh8bJzda9idvzgoqrKe0hQs77wCYbWkSPWH_H0_s750BjKVcez7tnL7C2O7MimZiUo Received: from [66.195.191.22] by web60724.mail.yahoo.com via HTTP; Wed, 13 Jun 2007 13:00:17 PDT X-Mailer: YahooMailRC/651.29 YahooMailWebService/0.7.41.16 Date: Wed, 13 Jun 2007 13:00:17 -0700 (PDT) From: Joe Souza Subject: Re: [Ips] iSNS database unique ID To: Paul Hughes , ips@ietf.org MIME-Version: 1.0 Message-ID: <533913.35302.qm@web60724.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0630999659==" Errors-To: ips-bounces@ietf.org --===============0630999659== Content-Type: multipart/alternative; boundary="0-574149153-1181764817=:35302" --0-574149153-1181764817=:35302 Content-Type: text/plain; charset=ascii Hi Paul, There is no unique ID per iSNS server instance. A vendor could, I suppose, implement something like this using a Vendor-Specific Message, but there is no generic support for this provided by the RFC. Generally, a specific instance of a server can be identified by its IP address. This, however, also will not be effective for you if the iSNS server is multi-homed. You are on the right track with your suggestion in the second paragraph of your email. What you would do is have each Portal send a DevAttrReg message specifying the Entity as the Message Key, with the Replace flag clear. Specify the Portal attributes after the Entity in the Operating Attributes (the Entity object must be repeated in the Operating Attributes). This will have the effect of adding the Portal to the Entity if the Portal was not already there, while leaving the remaining objects/attributes of the Entity intact. Using this method, you would still want your iSNS client to register at least the Entity and target Storage Node (iSCSI Name) objects upon target startup. The Portals would then add themselves to the Entity using the method that I describe above. -Joe ----- Original Message ---- From: Paul Hughes To: ips@ietf.org Sent: Wednesday, June 13, 2007 8:22:32 AM Subject: [Ips] iSNS database unique ID I am developing an iSNS client for an iSCSI target that supports multiple portals. It's possible that the target portals could be connected to different networks so I'd like to determine if each target portal has access to the same iSNS database. Section 6.9.1 of RFC 4171 (iSNS) states that an iSNS client can query for the iSNS Server Vendor OUI, but I assume that wouldn't be a unique value for the iSNS database. Is there some other value an iSNS client can query that would be unique to the iSNS database? If not, then I could have one portal register the target's Network Entity and then have each portal query the target's registration to determine if they can retrieve the target's Network Entity or not. Is there a better method? Thanks, Paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --0-574149153-1181764817=:35302 Content-Type: text/html; charset=ascii
Hi Paul,

There is no unique ID per iSNS server instance.  A vendor could, I suppose, implement something like this using a Vendor-Specific Message, but there is no generic support for this provided by the RFC.  Generally, a specific instance of a server can be identified by its IP address.  This, however, also will not be effective for you if the iSNS server is multi-homed.

You are on the right track with your suggestion in the second paragraph of your email.  What you would do is have each Portal send a DevAttrReg message specifying the Entity as the Message Key, with the Replace flag clear.  Specify the Portal attributes after the Entity in the Operating Attributes (the Entity object must be repeated in the Operating Attributes).  This will have the effect of adding the Portal to the Entity if the Portal was not already there, while leaving the remaining objects/attributes of the Entity intact.  Using this method, you would still want your iSNS client to register at least the Entity and target Storage Node (iSCSI Name) objects upon target startup.  The Portals would then add themselves to the Entity using the method that I describe above.

-Joe

----- Original Message ----
From: Paul Hughes <phughes@pillardata.com>
To: ips@ietf.org
Sent: Wednesday, June 13, 2007 8:22:32 AM
Subject: [Ips] iSNS database unique ID

I am developing an iSNS client for an iSCSI target that supports multiple portals.  It's possible that the target portals could be connected to different networks so I'd like to determine if each target portal has access to the same iSNS database.  Section 6.9.1 of RFC 4171 (iSNS) states that an iSNS client can query for the iSNS Server Vendor OUI, but I assume that wouldn't be a unique value for the iSNS database.  Is there some other value an iSNS client can query that would be unique to the iSNS database?
 
If not, then I could have one portal register the target's Network Entity and then have each portal query the target's registration to determine if they can retrieve the target's Network Entity or not.  Is there a better method?
 
Thanks,
Paul
 
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

--0-574149153-1181764817=:35302-- --===============0630999659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0630999659==-- From ips-bounces@ietf.org Mon Jun 25 15:51:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ub6-0001sj-JY; Mon, 25 Jun 2007 15:51:40 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I2uaV-0000ma-4p for ips-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 15:51:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uaT-0000eC-CM; Mon, 25 Jun 2007 15:51:01 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2uZW-0003vH-JE; Mon, 25 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7A517328B9; Mon, 25 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I2uZW-0000gV-9W; Mon, 25 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 25 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-impl-guide-09.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Corrections and Clarifications Author(s) : M. Chadalapaka Filename : draft-ietf-ips-iscsi-impl-guide-09.txt,.pdf Pages : 53 Date : 2007-6-25 iSCSI is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-impl-guide-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-09.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: <2007-6-25132902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-impl-guide-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-25132902.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Wed Jun 27 18:53:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3gOO-0006zT-5U; Wed, 27 Jun 2007 18:53:44 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I3gON-0006z1-5V for ips-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 18:53:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3gOM-0006yo-S7; Wed, 27 Jun 2007 18:53:42 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3gNu-0003EW-AD; Wed, 27 Jun 2007 18:53:42 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 47E7B3295E; Wed, 27 Jun 2007 22:53:14 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3gNu-0006WS-6X; Wed, 27 Jun 2007 18:53:14 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 27 Jun 2007 18:53:14 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'iSCSI Corrections and Clarifications' to Proposed Standard X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'iSCSI Corrections and Clarifications ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-09.txt Technical Summary iSCSI is a SCSI transport protocol that maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. Working Group Summary This document consists of clarification items collected during a period of more than one year based on implementation experience. A number of the items have engendered significant working group discussion about the appropriate clarification or change. The ips WG strongly supports the resulting clarifications and changes in this document. Document Quality There are numerous implementations of iSCSI, and the entire content of this document is based on issues that have arisen from implementation experience. There are a large number of individuals listed in the acknowledgements section who have contributed to this document based on their expertise and/or implementation experience. David Black (ips WG chair) and Julian Satran (RFC 3720 editor) have reviewed this document for the ips WG. IANA has performed an early review of the IANA actions. Personnel David Black is the Document Shepherd. Lars Eggert has reviewed this document for the IESG. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jun 27 19:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3gtc-0003L9-HX; Wed, 27 Jun 2007 19:26:00 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I3gtb-0003Kx-6f for ips-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 19:25:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3gta-0003Jo-Ht; Wed, 27 Jun 2007 19:25:58 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3gta-0004pS-9k; Wed, 27 Jun 2007 19:25:58 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l5RNP9Qg005472; Wed, 27 Jun 2007 19:25:09 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l5RNOwVb015576; Wed, 27 Jun 2007 19:25:07 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 19:25:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2007 19:25:04 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSCSI C&C draft approved Thread-Index: Ace5EmM4IQsVja9wRN+/PGmwokf2Rw== To: X-OriginalArrivalTime: 27 Jun 2007 23:25:05.0684 (UTC) FILETIME=[64E83D40:01C7B912] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.27.155732 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Black_David@emc.com, rddp@ietf.org Subject: [Ips] iSCSI C&C draft approved X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org With the recent IESG approval of the iSCSI Corrections and Clarifications draft, all of the IPS working group's drafts have been approved for RFC Publication. Congratulations and many thanks to the authors and everyone who has contributed. The IPS WG mailing list will remain open until the RFCs are actually published, and probably longer, as it's common knowledge that ips@ietf.org is a good place to ask questions about the protocols that we've worked on. In addition, the IESG has also recently approved the SCTP ADDIP draft - references to that draft have been holding up publication of the iSER and RDDP (WG) drafts. The result is that it's reasonable to expect RFC publication of all of the IPS WG drafts and all of the RDDP WG draft by the end of this year. I thought I'd share the good news. FYI, --David (IPS WG chair and RDDP WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jun 28 02:31:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3nXM-0002UX-Cv; Thu, 28 Jun 2007 02:31:28 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I3nXJ-0002KZ-PM for ips-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 02:31:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3nXI-0002K4-Lj; Thu, 28 Jun 2007 02:31:24 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3nXI-0006kX-8Q; Thu, 28 Jun 2007 02:31:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5S6UijC027014; Thu, 28 Jun 2007 09:31:04 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 09:30:44 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 09:30:44 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 09:30:44 +0300 Received: from [172.21.35.147] (esdhcp035147.research.nokia.com [172.21.35.147]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5S6UgZQ028656; Thu, 28 Jun 2007 09:30:42 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <2B620DF3-E111-4B17-ADCD-E77F0294D0B1@nokia.com> From: Lars Eggert Subject: Re: [Ips] iSCSI C&C draft approved Date: Thu, 28 Jun 2007 09:30:38 +0300 To: "ext ips-bounces@ietf.org" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 28 Jun 2007 06:30:44.0170 (UTC) FILETIME=[DB07F2A0:01C7B94D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ips@ietf.org, Black_David@emc.com, rddp@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0887085726==" Errors-To: ips-bounces@ietf.org --===============0887085726== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-112-694092643; protocol="application/pkcs7-signature" --Apple-Mail-112-694092643 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-6-28, at 2:25, ext ips-bounces@ietf.org wrote: > Congratulations and many thanks to the authors and everyone who has > contributed. Let me join in in thanking the WG for a very productive and successful effort - great job! Lars --Apple-Mail-112-694092643 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MjgwNjMwMzlaMCMGCSqGSIb3DQEJBDEWBBSdpnzxrTpzf3ML p8iUXOyaTtfQHTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAhWYlQLpTJQMpReTpQBt/LRRQ7M5E9zThVnyc/Wam+G7zM+Ca7W3G BPFfkfSSj6FnsB6GX4IGXmydeuitkblQMlFTPA2J5t6UvcsBhwWjYGfIgBar3DuyjBU23KIsvxQt 7o05DfAOXBB569DR5y3d8TpgAxdi6R//M76QRgYacw91tF2bX2Qh86U7b4xO9SBhI9LlpC78iQ9X 06FH0Y8Zc2R/IlMSFTOU0UxZbChMw+P0tGt6u15E6UXEvzdfKdYR0PRP5BtR+iVnOTBW4YtRwAqv FE+QvT9ABfs7c58RwM1L0ADhYsai1ChL5/gnfZ3Zv0wATvNXhkOxUj8xVdzjvAAAAAAAAA== --Apple-Mail-112-694092643-- --===============0887085726== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0887085726==-- From ips-bounces@ietf.org Fri Jun 29 08:25:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4FXC-0001fc-GE; Fri, 29 Jun 2007 08:25:10 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I4FXB-0001a8-GS for ips-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 08:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4FXB-0001ZA-5K for ips@ietf.org; Fri, 29 Jun 2007 08:25:09 -0400 Received: from imf22aec.mail.bellsouth.net ([205.152.59.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4FWV-00022m-5i for ips@ietf.org; Fri, 29 Jun 2007 08:25:08 -0400 Received: from ibm65aec.bellsouth.net ([74.234.49.49]) by imf22aec.mail.bellsouth.net with ESMTP id <20070629122426.REJF27077.imf22aec.mail.bellsouth.net@ibm65aec.bellsouth.net> for ; Fri, 29 Jun 2007 08:24:26 -0400 Received: from IVVTDKV0981 ([74.234.49.49]) by ibm65aec.bellsouth.net with SMTP id <20070629122426.GJNZ7077.ibm65aec.bellsouth.net@IVVTDKV0981>; Fri, 29 Jun 2007 08:24:26 -0400 Message-ID: <002601c7ba48$6ec14500$05faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Sandars, Ken" , "Parav Pandit" , References: <701777.88199.qm@web30104.mail.mud.yahoo.com> <368FBF3D8437A748BA8222526BF9309901DE70E6@aime2k302.adaptec.com> Subject: Re: [Ips] iSCSI protocol - use of SendTargets Date: Fri, 29 Jun 2007 08:24:25 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.1 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0479775726==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0479775726== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C7BA26.E77422A0" This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C7BA26.E77422A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Ken on the reading below. You may have alredy figured this = out but just to try to give a simple answer to your question ... suppose = you have built a box that has several targets each with different ip = addresses; the user at the initiator could just give one of the ip = addresses as the "discovery address"; this could be the address of only = one of the targets; the initiator can then log on as a discovery session = using that address and use SendTargets to find the names and addresses = of all targets. Eddy ----- Original Message -----=20 From: Sandars, Ken=20 To: Parav Pandit ; ips@ietf.org=20 Sent: Thursday, June 07, 2007 5:58 PM Subject: RE: [Ips] iSCSI protocol - use of SendTargets Hi Parav, Before any author shamelessly plugs their iSCSI publications, I = suggest you have a quick re-read of RFC3720.=20 In particular, section 3.4 pages 37-40 cover some really important = concepts that I think will help your understanding. Then jump to the = start of section 3, page 17 for more concepts and definitions. The specifics of the SendTargets command are in Appendix D. HTH Ken -------------------------------------------------------------------------= ----- From: Parav Pandit [mailto:paravpandit@yahoo.com]=20 Sent: Thursday, 7 June 2007 22:41 To: ips@ietf.org Subject: [Ips] iSCSI protocol - use of SendTargets Hi, I am new to iSCSI protocol and gearing up. Is this the right mailing list to ask questions related to iSCSI = protocol? if yes, 1. iSCSI target is identified by the network portal (IP + port). So once the iSCSI target is identified by the network portal and Login = to it is successful, why do we need to ask for SendTargets command? TargetName and TargetAddress returned are immaterial (because we = already know the target address to which we have logged-in), unless = there are multiple addresses for them and failover is required used. Or it is used for communicating different TCP port on which initiators = can send TUR, Inquiry, Read, Write commands? What is the expected information from the target in response to = SendTargets command? Regards, Parav Pandit -------------------------------------------------------------------------= ----- It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar.=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0023_01C7BA26.E77422A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree with Ken on the reading below. You may have = alredy=20 figured this out but just to try to give a simple answer to your = question ...=20 suppose you have built a box that has several targets each with = different ip=20 addresses; the user at the initiator could just give one of the ip = addresses as=20 the "discovery address"; this could be the address of only one of the = targets;=20 the initiator can then log on as a discovery session using that = address and=20 use SendTargets to find the names and addresses of all = targets.
 
Eddy
----- Original Message -----
From:=20 Sandars, Ken
Sent: Thursday, June 07, 2007 = 5:58=20 PM
Subject: RE: [Ips] iSCSI = protocol - use=20 of SendTargets

Hi Parav,
 
Before any author shamelessly plugs = their iSCSI=20 publications, I suggest you have a quick re-read of RFC3720.=20
 
In particular, section 3.4 pages 37-40 = cover some=20 really important concepts that I think will help your understanding. = Then jump=20 to the start of section 3, page 17 for more concepts and=20 definitions.
 
The specifics of the SendTargets command = are in=20 Appendix D.
 
HTH
Ken

From: Parav Pandit=20 [mailto:paravpandit@yahoo.com]
Sent: Thursday, 7 June 2007=20 22:41
To: ips@ietf.org
Subject: [Ips] iSCSI = protocol - use=20 of SendTargets

Hi,

I am new to iSCSI protocol and gearing up.
Is = this=20 the right mailing list to ask questions related to  iSCSI=20 protocol?

if yes,

1.  iSCSI target is identified by = the=20 network portal (IP + port).
So once the iSCSI target is identified = by the=20 network portal and Login to it is successful, why do we need to ask = for=20 SendTargets command?
TargetName and TargetAddress returned are = immaterial=20 (because we already know the target address to which we have = logged-in),=20 unless there are multiple addresses for them and failover is required=20 used.
Or it is used for communicating different TCP port on which=20 initiators can send TUR, Inquiry, Read, Write commands?

What is = the=20 expected information from the target in response to SendTargets=20 command?

Regards,
Parav Pandit

It's here! Your new message!
Get new=20 email alerts with the free Yahoo!=20 Toolbar.=20

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0023_01C7BA26.E77422A0-- --===============0479775726== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0479775726==-- From ips-bounces@ietf.org Sat Jun 30 05:05:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Yt9-0005a1-G7; Sat, 30 Jun 2007 05:05:07 -0400 Received: from ips by megatron.ietf.org with local (Exim 4.43) id 1I4Yt6-0005Tq-6O for ips-confirm+ok@megatron.ietf.org; Sat, 30 Jun 2007 05:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Yt2-0005Nz-Op for ips@ietf.org; Sat, 30 Jun 2007 05:05:01 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Ys9-0002k9-BU for ips@ietf.org; Sat, 30 Jun 2007 05:04:58 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l5U944Vo137762 for ; Sat, 30 Jun 2007 09:04:04 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5U944mh1736814 for ; Sat, 30 Jun 2007 11:04:04 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5U943D4016484 for ; Sat, 30 Jun 2007 11:04:04 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5U9438w016481; Sat, 30 Jun 2007 11:04:03 +0200 In-Reply-To: <002601c7ba48$6ec14500$05faa8c0@ivivity.com> To: "Eddy Quicksall" MIME-Version: 1.0 Subject: Re: [Ips] iSCSI protocol - use of SendTargets X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Julian Satran Message-ID: Date: Sat, 30 Jun 2007 12:04:02 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 30/06/2007 12:04:03, Serialize complete at 30/06/2007 12:04:03 X-Spam-Score: 0.1 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: ips@ietf.org, "Sandars, Ken" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2111846934==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============2111846934== Content-Type: multipart/alternative; boundary="=_alternative 0031CBD3C225730A_=" This is a multipart message in MIME format. --=_alternative 0031CBD3C225730A_= Content-Type: text/plain; charset="US-ASCII" Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. " reffer to? - Julo "Eddy Quicksall" 29/06/07 15:24 To "Sandars, Ken" , "Parav Pandit" , cc Subject Re: [Ips] iSCSI protocol - use of SendTargets I agree with Ken on the reading below. You may have alredy figured this out but just to try to give a simple answer to your question ... suppose you have built a box that has several targets each with different ip addresses; the user at the initiator could just give one of the ip addresses as the "discovery address"; this could be the address of only one of the targets; the initiator can then log on as a discovery session using that address and use SendTargets to find the names and addresses of all targets. Eddy ----- Original Message ----- From: Sandars, Ken To: Parav Pandit ; ips@ietf.org Sent: Thursday, June 07, 2007 5:58 PM Subject: RE: [Ips] iSCSI protocol - use of SendTargets Hi Parav, Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions. The specifics of the SendTargets command are in Appendix D. HTH Ken From: Parav Pandit [mailto:paravpandit@yahoo.com] Sent: Thursday, 7 June 2007 22:41 To: ips@ietf.org Subject: [Ips] iSCSI protocol - use of SendTargets Hi, I am new to iSCSI protocol and gearing up. Is this the right mailing list to ask questions related to iSCSI protocol? if yes, 1. iSCSI target is identified by the network portal (IP + port). So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command? TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used. Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands? What is the expected information from the target in response to SendTargets command? Regards, Parav Pandit It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0031CBD3C225730A_= Content-Type: text/html; charset="US-ASCII"
Ken - what exactly does "Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720. " reffer to? - Julo


"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>

29/06/07 15:24

To
"Sandars, Ken" <ken_sandars@adaptec.com>, "Parav Pandit" <paravpandit@yahoo.com>, <ips@ietf.org>
cc
Subject
Re: [Ips] iSCSI protocol - use of SendTargets





I agree with Ken on the reading below. You may have alredy figured this out but just to try to give a simple answer to your question ... suppose you have built a box that has several targets each with different ip addresses; the user at the initiator could just give one of the ip addresses as the "discovery address"; this could be the address of only one of the targets; the initiator can then log on as a discovery session using that address and use SendTargets to find the names and addresses of all targets.
 
Eddy
----- Original Message -----
From: Sandars, Ken
To: Parav Pandit ; ips@ietf.org
Sent: Thursday, June 07, 2007 5:58 PM
Subject: RE: [Ips] iSCSI protocol - use of SendTargets

Hi Parav,
 
Before any author shamelessly plugs their iSCSI publications, I suggest you have a quick re-read of RFC3720.
 
In particular, section 3.4 pages 37-40 cover some really important concepts that I think will help your understanding. Then jump to the start of section 3, page 17 for more concepts and definitions.
 
The specifics of the SendTargets command are in Appendix D.
 
HTH
Ken

From: Parav Pandit [mailto:paravpandit@yahoo.com]
Sent: Thursday, 7 June 2007 22:41
To: ips@ietf.org
Subject: [Ips] iSCSI protocol - use of SendTargets
Hi,

I am new to iSCSI protocol and gearing up.
Is this the right mailing list to ask questions related to  iSCSI protocol?

if yes,

1.  iSCSI target is identified by the network portal (IP + port).
So once the iSCSI target is identified by the network portal and Login to it is successful, why do we need to ask for SendTargets command?
TargetName and TargetAddress returned are immaterial (because we already know the target address to which we have logged-in), unless there are multiple addresses for them and failover is required used.
Or it is used for communicating different TCP port on which initiators can send TUR, Inquiry, Read, Write commands?

What is the expected information from the target in response to SendTargets command?

Regards,
Parav Pandit

It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.

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

--=_alternative 0031CBD3C225730A_=-- --===============2111846934== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2111846934==--