From ips-bounces@ietf.org Mon Aug 01 00:13:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzRgY-0005kB-3W; Mon, 01 Aug 2005 00:13:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzRgV-0005k6-78 for ips@megatron.ietf.org; Mon, 01 Aug 2005 00:13:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07255 for ; Mon, 1 Aug 2005 00:13:47 -0400 (EDT) Received: from relay2.mail.twtelecom.net ([216.54.204.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzSCh-0000bq-IL for ips@ietf.org; Mon, 01 Aug 2005 00:47:08 -0400 Received: from saturn.p3corpnet.pivot3.com (207-114-252-60.gen.twtelecom.net [207.114.252.60]) by relay2.mail.twtelecom.net (Postfix) with ESMTP id F0540C133 for ; Sun, 31 Jul 2005 23:13:42 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Re: ISID and DiscoveryRe: draft-ietf-ips-iscsi-impl-guide-00.txt Date: Sun, 31 Jul 2005 23:13:40 -0500 Message-ID: Thread-Topic: [Ips] Re: ISID and DiscoveryRe: draft-ietf-ips-iscsi-impl-guide-00.txt Thread-Index: AcWV/lbnb23Sk6eXQbCM4LpyG6nXCgAUHy0A From: "Galloway, Bill" To: X-Spam-Score: 0.7 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 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="===============0807062411==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0807062411== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5964F.63959FDA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5964F.63959FDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Julian, =20 I can accept that TPGT was not intended to be a target port-id by itself. However I am not aware of anything that says that multiple targets cannot share a TPGT. Am I missing something? =20 Bill Galloway ________________________________ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran Sent: Sunday, July 31, 2005 1:30 PM To: Mallikarjun C. Cc: IPS; ips-bounces@ietf.org Subject: Re: [Ips] Re: ISID and DiscoveryRe: draft-ietf-ips-iscsi-impl-guide-00.txt =09 =09 Mallikarjun,=20 =09 Option A was the one considered when iSCSI was written. Bill is talking about an implementation in which TPGT is an entity by its own used by several targets.=20 His parallel with the target port-id illustrates this point. TPGT however was not intended to be a target port-id by itself.=20 =09 Regards,=20 Julo=20 =09 =09 =09 "Mallikarjun C." =20 Sent by: ips-bounces@ietf.org=20 30-07-05 04:01=20 To IPS =20 cc Subject Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt =09 OK, I see two options in dealing with TPGTs. I sketched out the options=20 and respective implications below as I see them. Since I plan to=20 mandate one of the two based on the list feedback in the Implementer's=20 guide, please review carefully - your initiator, target or NIC *may be*=20 affected. =09 I personally am leaning towards Option A because I see it's closest to=20 RFC 3720 semantics and would require no new conceptual additions. =09 Mallikarjun =09 Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com =09 =09 Options: =09 A. TPGTs are always Node-scoped. If Node name isn't specified in the=20 discovery Login Request PDU, TPGT is meaningless and can't be inferred=20 (or inferred to be invalid). =09 B. TPGTs are always Node-scoped. If Node name isn't specified in the=20 discovery Login Request PDU, a special "No-Name" iSCSI Node is implied.=20 This No-Name iSCSI Node has its own TPGT numbering space - one tag for=20 each physically possible portal group - and thus the TPGT can be inferred. =09 Implications - =09 Option A: =09 1. There can only be one no-named discovery session to a Network Entity=20 with a given InitiatorName-ISID combination. A new no-named discovery=20 session reinstates the first. If this is your current behavior, speak up. =09 2. An initiator doing parallel discovery probing of multiple IP=20 addresses using a generic InitiatorName-ISID tuple may see all but one=20 of its probe attempts fail in each set of IP addresses hosted by one=20 Network Entity (if you're doing SLP/iSNS-based discovery, this may be a=20 no-op). =09 3. To realize the session reinstatement of a no-named discovery session=20 on matching InitiatorName-ISID, target CPU software may have to be=20 involved in Login processing for no-named discovery sessions. Depending=20 on your implementation, it may not all be offloaded to hardware. =09 Option B: 1. There can be multiple no-named discovery sessions to a Network Entity=20 with a given InitiatorName-ISID combination - one for each TPGT of the=20 No-Name Node. A new no-named discovery session reinstates an existing=20 discovery session only if the TPGT matches. If this is your current=20 behavior, speak up. =09 2. An initiator doing parallel discovery probing of multiple IP=20 addresses using a generic InitiatorName-ISID tuple may have all=20 successful probes, but all such probes of each set of IP addresses=20 hosted by one Network Entity return duplicate discovery data (if you're=20 doing SLP/iSNS-based discovery, this may be a no-op). =09 3. For some implementations, it is technically feasible to offload the=20 login processing for a no-named discovery session. Target CPU software=20 is not required to be involved (although your code may have other=20 reasons to get involved). =09 4. Introduces a new notion of a "No-Name" iSCSI Node that must host all=20 physically possible portal groups. No-Name Node is however not a=20 full-fledged Node because TargetPortalGroupTag must not be returned -=20 though it can be inferred - on no-named discovery sessions per RFC 3720,=20 and is limited to hosting only the no-named discovery sessions. =09 =09 =09 =09 =09 =09 =09 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 =09 ------_=_NextPart_001_01C5964F.63959FDA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Julian,
 
I can accept that TPGT was not intended to be = a target=20 port-id by itself.  However I am not aware of anything that says = that=20 multiple targets cannot share a TPGT.  Am I missing=20 something?
 
Bill Galloway

From: ips-bounces@ietf.org=20 [mailto:ips-bounces@ietf.org] On Behalf Of Julian=20 Satran
Sent: Sunday, July 31, 2005 1:30 PM
To: = Mallikarjun=20 C.
Cc: IPS; ips-bounces@ietf.org
Subject: Re: = [Ips] Re:=20 ISID and DiscoveryRe:=20 draft-ietf-ips-iscsi-impl-guide-00.txt


Mallikarjun, =

Option A was the one considered when iSCSI = was written.=20 Bill is talking about an implementation in which TPGT is an entity by = its own=20 used by several targets.
His parallel=20 with the target port-id illustrates this point. TPGT however was not = intended=20 to be a target port-id by itself.

Regards,
Julo=20


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

30-07-05 04:01

To
IPS = <ips@ietf.org>=20
cc
Subject
Re: [Ips] Re: ISID and = Discovery=20 Re:      =20 =  draft-ietf-ips-iscsi-impl-guide-00.txt
<= BR>
=




OK, I see two options in dealing with TPGTs.  I sketched = out the=20 options
and respective implications below as I see them. =  Since I=20 plan to
mandate one of the two based on the list feedback in the=20 Implementer's
guide, please review carefully - your initiator, = target or=20 NIC *may be*
affected.

I personally am leaning towards = Option A=20 because I see it's closest to
RFC 3720 semantics and would require = no new=20 conceptual additions.

Mallikarjun

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


Options:

A. TPGTs are always = Node-scoped.=20  If Node name isn't specified in the
discovery Login Request = PDU,=20 TPGT is meaningless and can't be inferred
(or inferred to be=20 invalid).

B. TPGTs are always Node-scoped.  If Node name = isn't=20 specified in the
discovery Login Request PDU, a special "No-Name" = iSCSI=20 Node is implied.
 This No-Name iSCSI Node has its own TPGT = numbering=20 space - one tag for
each physically possible portal group - and = thus the=20 TPGT can be inferred.

Implications -

Option A:

1. = There=20 can only be one no-named discovery session to a Network Entity =
with a=20 given InitiatorName-ISID combination. A new no-named discovery =
session=20 reinstates the first.  If this is your current behavior, speak=20 up.

2. An initiator doing parallel discovery probing of = multiple IP=20
addresses using a generic InitiatorName-ISID tuple may see all but = one=20
of its probe attempts fail in each set of IP addresses hosted by = one=20
Network Entity (if you're doing SLP/iSNS-based discovery, this may = be a=20
no-op).

3. To realize the session reinstatement of a = no-named=20 discovery session
on matching InitiatorName-ISID, target CPU = software may=20 have to be
involved in Login processing for no-named discovery = sessions.=20  Depending
on your implementation, it may not all be = offloaded to=20 hardware.

Option B:
1. There can be multiple no-named = discovery=20 sessions to a Network Entity
with a given InitiatorName-ISID = combination -=20 one for each TPGT of the
No-Name Node. A new no-named discovery = session=20 reinstates an existing
discovery session only if the TPGT matches. =  If this is your current
behavior, speak up.

2. An = initiator=20 doing parallel discovery probing of multiple IP
addresses using a = generic=20 InitiatorName-ISID tuple may have all
successful probes, but all = such=20 probes of each set of IP addresses
hosted by one Network Entity = return=20 duplicate discovery data (if you're
doing SLP/iSNS-based = discovery, this=20 may be a no-op).

3. For some implementations, it is technically = feasible to offload the
login processing for a no-named discovery = session.=20  Target CPU software
is not required to be involved (although = your=20 code may have other
reasons to get involved).

4. Introduces = a new=20 notion of a "No-Name" iSCSI Node that must host all
physically = possible=20 portal groups.  No-Name Node is however not a
full-fledged = Node=20 because TargetPortalGroupTag must not be returned -
though it can = be=20 inferred - on no-named discovery sessions per RFC 3720,
and is = limited to=20 hosting only the no-named discovery=20 = sessions.







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

------_=_NextPart_001_01C5964F.63959FDA-- --===============0807062411== 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 --===============0807062411==-- From ips-bounces@ietf.org Mon Aug 01 04:58:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzW7l-0005vn-Er; Mon, 01 Aug 2005 04:58:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzW7g-0005up-EO for ips@megatron.ietf.org; Mon, 01 Aug 2005 04:58:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06364 for ; Mon, 1 Aug 2005 04:58:10 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzWdu-0005IA-2f for ips@ietf.org; Mon, 01 Aug 2005 05:31:32 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j718vwmp026212 for ; Mon, 1 Aug 2005 08:57:58 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j718vwNs188952 for ; Mon, 1 Aug 2005 10:57:58 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j718vvrh012524 for ; Mon, 1 Aug 2005 10:57:57 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j718vvv4012520; Mon, 1 Aug 2005 10:57:57 +0200 In-Reply-To: To: "Galloway, Bill" Subject: RE: [Ips] Re: ISID and DiscoveryRe: draft-ietf-ips-iscsi-impl-guide-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M6_06302005 Beta 4NP June 30, 2005 From: Julian Satran Message-ID: Date: Mon, 1 Aug 2005 10:57:56 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 01/08/2005 11:57:57, Serialize complete at 01/08/2005 11:57:57 X-Spam-Score: 0.6 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Cc: snia-ips@snia.org, 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="===============1384906532==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1384906532== Content-Type: multipart/alternative; boundary="=_alternative 00307D0FC1257050_=" This is a multipart message in MIME format. --=_alternative 00307D0FC1257050_= Content-Type: text/plain; charset="US-ASCII" Bill, TPGT is just a value. If by sharing you mean an implementation may use internally TPGT to indicate the same physical set of ports that is perfectly legitimate however the standard does no require that and does not attach any meaning to the TPGT beyond the combinationofTarget-Name+TPGT. If you are looking to standardize this type of behavior RFC3720 is the probably not the right place as TPGT has no role on the wire by itself (only in combination with a target name) although that may be a decent practice. You might want to look to SNIA that attempts to standardize adapter management in their IPS working group and may consider this type of behavior in implementations compatible with their management interfaces (that is why I am copying them). Julo "Galloway, Bill" Sent by: ips-bounces@ietf.org 01-08-05 06:13 To cc Subject RE: [Ips] Re: ISID and DiscoveryRe: draft-ietf-ips-iscsi-impl-guide-00.txt Julian, I can accept that TPGT was not intended to be a target port-id by itself. However I am not aware of anything that says that multiple targets cannot share a TPGT. Am I missing something? Bill Galloway From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran Sent: Sunday, July 31, 2005 1:30 PM To: Mallikarjun C. Cc: IPS; ips-bounces@ietf.org Subject: Re: [Ips] Re: ISID and DiscoveryRe: draft-ietf-ips-iscsi-impl-guide-00.txt Mallikarjun, Option A was the one considered when iSCSI was written. Bill is talking about an implementation in which TPGT is an entity by its own used by several targets. His parallel with the target port-id illustrates this point. TPGT however was not intended to be a target port-id by itself. Regards, Julo "Mallikarjun C." Sent by: ips-bounces@ietf.org 30-07-05 04:01 To IPS cc Subject Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt OK, I see two options in dealing with TPGTs. I sketched out the options and respective implications below as I see them. Since I plan to mandate one of the two based on the list feedback in the Implementer's guide, please review carefully - your initiator, target or NIC *may be* affected. I personally am leaning towards Option A because I see it's closest to RFC 3720 semantics and would require no new conceptual additions. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Options: A. TPGTs are always Node-scoped. If Node name isn't specified in the discovery Login Request PDU, TPGT is meaningless and can't be inferred (or inferred to be invalid). B. TPGTs are always Node-scoped. If Node name isn't specified in the discovery Login Request PDU, a special "No-Name" iSCSI Node is implied. This No-Name iSCSI Node has its own TPGT numbering space - one tag for each physically possible portal group - and thus the TPGT can be inferred. Implications - Option A: 1. There can only be one no-named discovery session to a Network Entity with a given InitiatorName-ISID combination. A new no-named discovery session reinstates the first. If this is your current behavior, speak up. 2. An initiator doing parallel discovery probing of multiple IP addresses using a generic InitiatorName-ISID tuple may see all but one of its probe attempts fail in each set of IP addresses hosted by one Network Entity (if you're doing SLP/iSNS-based discovery, this may be a no-op). 3. To realize the session reinstatement of a no-named discovery session on matching InitiatorName-ISID, target CPU software may have to be involved in Login processing for no-named discovery sessions. Depending on your implementation, it may not all be offloaded to hardware. Option B: 1. There can be multiple no-named discovery sessions to a Network Entity with a given InitiatorName-ISID combination - one for each TPGT of the No-Name Node. A new no-named discovery session reinstates an existing discovery session only if the TPGT matches. If this is your current behavior, speak up. 2. An initiator doing parallel discovery probing of multiple IP addresses using a generic InitiatorName-ISID tuple may have all successful probes, but all such probes of each set of IP addresses hosted by one Network Entity return duplicate discovery data (if you're doing SLP/iSNS-based discovery, this may be a no-op). 3. For some implementations, it is technically feasible to offload the login processing for a no-named discovery session. Target CPU software is not required to be involved (although your code may have other reasons to get involved). 4. Introduces a new notion of a "No-Name" iSCSI Node that must host all physically possible portal groups. No-Name Node is however not a full-fledged Node because TargetPortalGroupTag must not be returned - though it can be inferred - on no-named discovery sessions per RFC 3720, and is limited to hosting only the no-named discovery sessions. _______________________________________________ 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 00307D0FC1257050_= Content-Type: text/html; charset="US-ASCII"
Bill,

TPGT is just a value. If by sharing you mean an implementation may use internally TPGT to indicate the same physical set of ports that is perfectly legitimate however the standard does no require that and does not attach any meaning to the TPGT beyond the combinationofTarget-Name+TPGT.

If you are looking to standardize this type of  behavior RFC3720 is the probably not the right place as TPGT has no role on the wire by itself (only in combination with a target name) although that may be a decent practice. You might want to look to SNIA that attempts to standardize adapter management in their IPS working group and may consider this type of behavior in implementations compatible with their management interfaces (that is why I am copying them).

Julo



"Galloway, Bill" <billg@pivot3.com>
Sent by: ips-bounces@ietf.org

01-08-05 06:13

To
<ips@ietf.org>
cc
Subject
RE: [Ips] Re: ISID and        DiscoveryRe:        draft-ietf-ips-iscsi-impl-guide-00.txt





Julian,
 
I can accept that TPGT was not intended to be a target port-id by itself.  However I am not aware of anything that says that multiple targets cannot share a TPGT.  Am I missing something?
 
Bill Galloway

From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Julian Satran
Sent: Sunday, July 31, 2005 1:30 PM
To: Mallikarjun C.
Cc: IPS; ips-bounces@ietf.org
Subject: Re: [Ips] Re: ISID and DiscoveryRe: draft-ietf-ips-iscsi-impl-guide-00.txt

Mallikarjun,

Option A was the one considered when iSCSI was written. Bill is talking about an implementation in which TPGT is an entity by its own used by several targets.
His parallel with the target port-id illustrates this point. TPGT however was not intended to be a target port-id by itself.

Regards,
Julo

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

30-07-05 04:01


To
IPS <ips@ietf.org>
cc
Subject
Re: [Ips] Re: ISID and Discovery Re:        draft-ietf-ips-iscsi-impl-guide-00.txt







OK, I see two options in dealing with TPGTs.  I sketched out the options
and respective implications below as I see them.  Since I plan to
mandate one of the two based on the list feedback in the Implementer's
guide, please review carefully - your initiator, target or NIC *may be*
affected.

I personally am leaning towards Option A because I see it's closest to
RFC 3720 semantics and would require no new conceptual additions.

Mallikarjun

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


Options:

A. TPGTs are always Node-scoped.  If Node name isn't specified in the
discovery Login Request PDU, TPGT is meaningless and can't be inferred
(or inferred to be invalid).

B. TPGTs are always Node-scoped.  If Node name isn't specified in the
discovery Login Request PDU, a special "No-Name" iSCSI Node is implied.
This No-Name iSCSI Node has its own TPGT numbering space - one tag for
each physically possible portal group - and thus the TPGT can be inferred.

Implications -

Option A:

1. There can only be one no-named discovery session to a Network Entity
with a given InitiatorName-ISID combination. A new no-named discovery
session reinstates the first.  If this is your current behavior, speak up.

2. An initiator doing parallel discovery probing of multiple IP
addresses using a generic InitiatorName-ISID tuple may see all but one
of its probe attempts fail in each set of IP addresses hosted by one
Network Entity (if you're doing SLP/iSNS-based discovery, this may be a
no-op).

3. To realize the session reinstatement of a no-named discovery session
on matching InitiatorName-ISID, target CPU software may have to be
involved in Login processing for no-named discovery sessions.  Depending
on your implementation, it may not all be offloaded to hardware.

Option B:
1. There can be multiple no-named discovery sessions to a Network Entity
with a given InitiatorName-ISID combination - one for each TPGT of the
No-Name Node. A new no-named discovery session reinstates an existing
discovery session only if the TPGT matches.  If this is your current
behavior, speak up.

2. An initiator doing parallel discovery probing of multiple IP
addresses using a generic InitiatorName-ISID tuple may have all
successful probes, but all such probes of each set of IP addresses
hosted by one Network Entity return duplicate discovery data (if you're
doing SLP/iSNS-based discovery, this may be a no-op).

3. For some implementations, it is technically feasible to offload the
login processing for a no-named discovery session.  Target CPU software
is not required to be involved (although your code may have other
reasons to get involved).

4. Introduces a new notion of a "No-Name" iSCSI Node that must host all
physically possible portal groups.  No-Name Node is however not a
full-fledged Node because TargetPortalGroupTag must not be returned -
though it can be inferred - on no-named discovery sessions per RFC 3720,
and is limited to hosting only the no-named discovery sessions.







_______________________________________________
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 00307D0FC1257050_=-- --===============1384906532== 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 --===============1384906532==-- From ips-bounces@ietf.org Mon Aug 01 13:58:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzeYZ-0003Gb-SC; Mon, 01 Aug 2005 13:58:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzeYY-0003GW-UN for ips@megatron.ietf.org; Mon, 01 Aug 2005 13:58:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28085 for ; Mon, 1 Aug 2005 13:58:27 -0400 (EDT) From: elizabeth.rodriguez@dothill.com Received: from artecon.dothill.com ([155.254.128.254] helo=dothill.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzf4r-0005NF-Qa for ips@ietf.org; Mon, 01 Aug 2005 14:31:55 -0400 Received: from exchange.artecon.com (exchange [206.6.182.75]) by dothill.com (8.12.9+Sun/8.12.5) with ESMTP id j71HnENO024302 for ; Mon, 1 Aug 2005 10:49:14 -0700 (PDT) Received: by EXCHANGE with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Aug 2005 10:57:38 -0700 Message-ID: To: ips@ietf.org Date: Mon, 1 Aug 2005 10:58:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ips] Resignation as chair X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hello all, I am sorry to inform the group that due to a change in responsibilities at my company, I am resigning as chair of the IPS working group. Thanks to everyone that has participated and helped me over the last several years, especially David Black, who will continue as chair. Elizabeth Rodriguez _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 03 12:31:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0M9K-0003PG-8B; Wed, 03 Aug 2005 12:31:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0M9I-0003PA-Pt for ips@megatron.ietf.org; Wed, 03 Aug 2005 12:31:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29077 for ; Wed, 3 Aug 2005 12:31:18 -0400 (EDT) Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Mg1-0000mf-2J for ips@ietf.org; Wed, 03 Aug 2005 13:05:09 -0400 Received: from smtp1.corp.netapp.com (10.57.156.124) by mx2.netapp.com with ESMTP; 03 Aug 2005 09:31:10 -0700 X-IronPort-AV: i="3.95,163,1120460400"; d="scan'208,217"; a="299248267:sNHT23968228" Received: from svlexc03.hq.netapp.com (svlexc03.corp.netapp.com [10.57.156.149]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id j73GVA0A024902 for ; Wed, 3 Aug 2005 09:31:10 -0700 (PDT) Received: from RTPEXC02.hq.netapp.com ([10.100.157.167]) by svlexc03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Aug 2005 09:31:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Aug 2005 12:31:09 -0400 Message-ID: Thread-Topic: iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF) Thread-Index: AcWYSMFt80eteiIUTjan/KQ7ZvZghw== From: "Pittman, Joseph" To: X-OriginalArrivalTime: 03 Aug 2005 16:31:10.0543 (UTC) FILETIME=[C1BDB5F0:01C59848] X-Spam-Score: 0.8 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Subject: [Ips] iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF) 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="===============0516161412==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0516161412== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59848.C154DD7D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59848.C154DD7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a question about section 4 of the iSCSI implementer's guide, draft-ietf-ips-iscsi-impl-guide-00.txt. =20 In particular, steps e) and f) in the target's sequence of actions states the following: =20 The Target: =20 e) Takes note of last-sent StatSN on each of the connections in the iSCSI session(s) (one or more) sharing the affected tasks, and waits for acknowledgement of each StatSN (may solicit for acknowledgement by way of a NOP-In). If some tasks originate from non-iSCSI I_T_L nexuses then the means by which the target insures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s). =20 f) Sends the task set management response to the issuing initiator. =20 That is: - The target must wait until it has positive acknowledgement that all responses sent for all POTENTIALLY AFFECTED commands were received by their respective initiators - THEN the target may send the TMF response. =20 =20 =20 For the purposes of this mail message, I would like to separate the requirement imposed by steps e) and f), into two separate sub-requirements: =20 Sub-requirement 1, pertaining to: Status/Responses for iSCSI requests (including SCSI tasks) being conducted on the SAME iSCSI session as the TMF itself. =20 Sub-requirement 2, pertaining to: Status/Responses for SCSI tasks being conducted on OTHER SCSI I_T_L nexuses =20 =20 =20 I understand Sub-requirement 1 above. Section 4.1.3 of the implementer's guide, and especially bullet item 2 ('single ordered response flow') clearly explains why the target steps e) and f) are necessary. The iSCSI multi-connection session feature introduces the possibility of out of order arrival of responses at the initiator; it is the responsibility of the iSCSI initiator to reconstruct the in-order response stream, to satisfy the expectations of the SCSI layer. =20 But I cannot understand why the iSCSI specification imposes Sub-requirement 2. =20 - The SCSI-2 and SCSI-3 specifications do not impose ordering constraints between two separate SCSI nexuses =20 - iSCSI is merely a transport protocol for SCSI, so it seems out of place for the iSCSI spec to be imposing additional requirements on SCSI or other transports =20 - It may not be possible to satisfy this sub-requirement with certain other transports =20 - There are many examples of configurations with multi-pathed access from a single host system to SCSI targets using non-iSCSI transports, without the "benefit" of sub-requirement 2. =20 And the current version of the implementer's guide does not appear to shed light on the matter. =20 Can anyone think of a justification for the inclusion of Sub-requirement 2 in the iSCSI specification? If so, should this topic be discussed in the implementer's guide? =20 Thanks! -- Joe Pittman jpittman@netapp.com =20 ------_=_NextPart_001_01C59848.C154DD7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
This is a question about = section 4 of the=20 iSCSI implementer's
guide,=20 draft-ietf-ips-iscsi-impl-guide-00.txt.
 
In particular, steps e) and f) = in the=20 target's sequence of actions
states the following:
 
  The Target:
 
     e) = Takes note of=20 last-sent StatSN on each of the=20 connections
       in the iSCSI = session(s) (one=20 or more) sharing the affected
       = tasks, and=20 waits for acknowledgement of each StatSN=20 (may
       solicit for acknowledgement = by way=20 of a NOP-In). If some
       tasks = originate=20 from non-iSCSI I_T_L nexuses then the=20 means
       by which the target = insures that=20 all affected tasks have
       returned = their=20 status to the initiator are defined by=20 the
       specific non-iSCSI transport = protocol(s).
 
     f) = Sends the task=20 set management response to the=20 issuing
        = initiator.
 

That is:
- The target = must wait=20 until it has positive acknowledgement that all
  responses sent = for all=20 POTENTIALLY AFFECTED commands were received by
  their = respective=20 initiators
- THEN the target may send the TMF response.
 
 
 
For the purposes of this mail = message, I=20 would like to separate the
requirement imposed by steps = e) and=20 f), into two separate
sub-requirements:
 
Sub-requirement 1, pertaining = to:
 =20 Status/Responses for iSCSI requests (including SCSI tasks) = being
 =20 conducted on the SAME iSCSI session as the TMF itself.
 
Sub-requirement 2, pertaining = to:
 =20 Status/Responses for SCSI tasks being conducted on OTHER SCSI
  = I_T_L=20 nexuses
 
 
 
I understand Sub-requirement 1 = above. =20 Section 4.1.3 of the implementer's
guide, and especially bullet item = 2=20 ('single ordered response flow')
clearly explains why the target = steps e) and=20 f) are necessary.
The iSCSI multi-connection session feature = introduces the=20 possibility
of out of order arrival of responses at the initiator; it = is=20 the
responsibility of the iSCSI initiator to reconstruct the=20 in-order
response stream, to satisfy the expectations of the SCSI=20 layer.
 

But I cannot understand why = the iSCSI=20 specification imposes
Sub-requirement 2.
 
- The SCSI-2 and SCSI-3 = specifications do=20 not impose ordering
  constraints between two separate SCSI=20 nexuses
 
- iSCSI is merely a transport = protocol for=20 SCSI, so it seems
  out of place for the iSCSI spec to be = imposing=20 additional
  requirements on SCSI or other = transports
 
- It may not be possible to = satisfy this=20 sub-requirement with
  certain other transports
 
- There are many examples of = configurations=20 with multi-pathed access
  from a single host system to SCSI = targets=20 using non-iSCSI transports,
  without the "benefit" of = sub-requirement=20 2.
 

And the current version of = the=20 implementer's guide does not appear
to shed light on the = matter.
 
Can anyone think of a = justification for the=20 inclusion of
Sub-requirement 2 in the iSCSI specification?  If = so,=20 should this
topic be discussed in the implementer's = guide?
 
Thanks!
--
Joe = Pittman
jpittman@netapp.com
=00 ------_=_NextPart_001_01C59848.C154DD7D-- --===============0516161412== 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 --===============0516161412==-- From ips-bounces@ietf.org Wed Aug 03 13:26:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0N0N-0003zu-Bm; Wed, 03 Aug 2005 13:26:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0N0L-0003zm-Qb; Wed, 03 Aug 2005 13:26:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02309; Wed, 3 Aug 2005 13:26:06 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0NX2-0003Ab-Ed; Wed, 03 Aug 2005 13:59:59 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j73HPrOA147852; Wed, 3 Aug 2005 17:25:53 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j73HPrX4188352; Wed, 3 Aug 2005 19:25:53 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j73HPrxM026389; Wed, 3 Aug 2005 19:25:53 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j73HPrvq026383; Wed, 3 Aug 2005 19:25:53 +0200 In-Reply-To: To: "Pittman, Joseph" Subject: Re: [Ips] iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF) MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M6_06302005 Beta 4NP June 30, 2005 From: Julian Satran Message-ID: Date: Wed, 3 Aug 2005 19:25:51 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 03/08/2005 20:25:52, Serialize complete at 03/08/2005 20:25:52 X-Spam-Score: 1.5 (+) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: ips@ietf.org, ips-bounces@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1351524806==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1351524806== Content-Type: multipart/alternative; boundary="=_alternative 005D2B84C1257052_=" This is a multipart message in MIME format. --=_alternative 005D2B84C1257052_= Content-Type: text/plain; charset="US-ASCII" SCSI requires that no packets pertained to the aborted tasks be received after the response to the TMF (even if they are multi-NEXI). However for the case of different NEXI you may have a point in that different NEXI may not even all be iSCSI (SAM does not required this type of homogeneity). For other NEXI the requirement can be weakened with a statement of "if this function is available in the transport of the other NEXI". Julo "Pittman, Joseph" Sent by: ips-bounces@ietf.org 03-08-05 18:31 To cc Subject [Ips] iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF) This is a question about section 4 of the iSCSI implementer's guide, draft-ietf-ips-iscsi-impl-guide-00.txt. In particular, steps e) and f) in the target's sequence of actions states the following: The Target: e) Takes note of last-sent StatSN on each of the connections in the iSCSI session(s) (one or more) sharing the affected tasks, and waits for acknowledgement of each StatSN (may solicit for acknowledgement by way of a NOP-In). If some tasks originate from non-iSCSI I_T_L nexuses then the means by which the target insures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s). f) Sends the task set management response to the issuing initiator. That is: - The target must wait until it has positive acknowledgement that all responses sent for all POTENTIALLY AFFECTED commands were received by their respective initiators - THEN the target may send the TMF response. For the purposes of this mail message, I would like to separate the requirement imposed by steps e) and f), into two separate sub-requirements: Sub-requirement 1, pertaining to: Status/Responses for iSCSI requests (including SCSI tasks) being conducted on the SAME iSCSI session as the TMF itself. Sub-requirement 2, pertaining to: Status/Responses for SCSI tasks being conducted on OTHER SCSI I_T_L nexuses I understand Sub-requirement 1 above. Section 4.1.3 of the implementer's guide, and especially bullet item 2 ('single ordered response flow') clearly explains why the target steps e) and f) are necessary. The iSCSI multi-connection session feature introduces the possibility of out of order arrival of responses at the initiator; it is the responsibility of the iSCSI initiator to reconstruct the in-order response stream, to satisfy the expectations of the SCSI layer. But I cannot understand why the iSCSI specification imposes Sub-requirement 2. - The SCSI-2 and SCSI-3 specifications do not impose ordering constraints between two separate SCSI nexuses - iSCSI is merely a transport protocol for SCSI, so it seems out of place for the iSCSI spec to be imposing additional requirements on SCSI or other transports - It may not be possible to satisfy this sub-requirement with certain other transports - There are many examples of configurations with multi-pathed access from a single host system to SCSI targets using non-iSCSI transports, without the "benefit" of sub-requirement 2. And the current version of the implementer's guide does not appear to shed light on the matter. Can anyone think of a justification for the inclusion of Sub-requirement 2 in the iSCSI specification? If so, should this topic be discussed in the implementer's guide? Thanks! -- Joe Pittman jpittman@netapp.com_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005D2B84C1257052_= Content-Type: text/html; charset="US-ASCII"
SCSI requires that no packets pertained to the aborted tasks be received after the response to the TMF (even if they are multi-NEXI).
However for the case of different NEXI you may have a point in that different NEXI may not even all be iSCSI (SAM does not required this type of homogeneity).
For other NEXI the requirement can be weakened with a statement of "if this function is available in the transport of the other NEXI".


Julo


"Pittman, Joseph" <Joseph.Pittman@netapp.com>
Sent by: ips-bounces@ietf.org

03-08-05 18:31

To
<ips@ietf.org>
cc
Subject
[Ips]         iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF)





This is a question about section 4 of the iSCSI implementer's
guide, draft-ietf-ips-iscsi-impl-guide-00.txt.
 
In particular, steps e) and f) in the target's sequence of actions
states the following:
 
  The Target:
 
     e) Takes note of last-sent StatSN on each of the connections
      in the iSCSI session(s) (one or more) sharing the affected
      tasks, and waits for acknowledgement of each StatSN (may
      solicit for acknowledgement by way of a NOP-In). If some
      tasks originate from non-iSCSI I_T_L nexuses then the means
      by which the target insures that all affected tasks have
      returned their status to the initiator are defined by the
      specific non-iSCSI transport protocol(s).
 
     f) Sends the task set management response to the issuing
       initiator.
 

That is:
- The target must wait until it has positive acknowledgement that all
 responses sent for all POTENTIALLY AFFECTED commands were received by
 their respective initiators
- THEN the target may send the TMF response.
 
 
 
For the purposes of this mail message, I would like to separate the
requirement imposed by steps e) and f), into two separate
sub-requirements:
 
Sub-requirement 1, pertaining to:
 Status/Responses for iSCSI requests (including SCSI tasks) being
 conducted on the SAME iSCSI session as the TMF itself.
 
Sub-requirement 2, pertaining to:
 Status/Responses for SCSI tasks being conducted on OTHER SCSI
 I_T_L nexuses
 
 
 
I understand Sub-requirement 1 above.  Section 4.1.3 of the implementer's
guide, and especially bullet item 2 ('single ordered response flow')
clearly explains why the target steps e) and f) are necessary.
The iSCSI multi-connection session feature introduces the possibility
of out of order arrival of responses at the initiator; it is the
responsibility of the iSCSI initiator to reconstruct the in-order
response stream, to satisfy the expectations of the SCSI layer.
 

But I cannot understand why the iSCSI specification imposes
Sub-requirement 2.
 
- The SCSI-2 and SCSI-3 specifications do not impose ordering
 constraints between two separate SCSI nexuses
 
- iSCSI is merely a transport protocol for SCSI, so it seems
 out of place for the iSCSI spec to be imposing additional
 requirements on SCSI or other transports
 
- It may not be possible to satisfy this sub-requirement with
 certain other transports
 
- There are many examples of configurations with multi-pathed access
 from a single host system to SCSI targets using non-iSCSI transports,
 without the "benefit" of sub-requirement 2.
 

And the current version of the implementer's guide does not appear
to shed light on the matter.
 
Can anyone think of a justification for the inclusion of
Sub-requirement 2 in the iSCSI specification?  If so, should this
topic be discussed in the implementer's guide?
 
Thanks!
--
Joe Pittman
jpittman@netapp.com_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 005D2B84C1257052_=-- --===============1351524806== 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 --===============1351524806==-- From ips-bounces@ietf.org Wed Aug 03 13:33:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0N7l-0007cq-46; Wed, 03 Aug 2005 13:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0N7h-0007cf-50 for ips@megatron.ietf.org; Wed, 03 Aug 2005 13:33:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02693 for ; Wed, 3 Aug 2005 13:33:42 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0NeN-0003XK-94 for ips@ietf.org; Wed, 03 Aug 2005 14:07:34 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mononoke.wasabisystems.com (Postfix) with ESMTP id CFB9187081; Wed, 3 Aug 2005 13:33:26 -0400 (EDT) In-Reply-To: <42EAD17E.5040703@rose.hp.com> References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> <9a00dc707c09c8d4e58ac7f8a9f980fb@wasabisystems.com> <5bed23bfdf7ace05d6e538adb57c0381@wasabisystems.com> <42E81C7E.5020907@rose.hp.com> <9e8ad9858bd06593b8d2ecde86f96440@wasabisystems.com> <42EAD17E.5040703@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <02bcc5c4eb5c765739541c226dc4eca1@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt Date: Wed, 3 Aug 2005 10:33:25 -0700 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0723569653==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0723569653== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8-901801579" Content-Transfer-Encoding: 7bit --Apple-Mail-8-901801579 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jul 29, 2005, at 6:01 PM, Mallikarjun C. wrote: > OK, I see two options in dealing with TPGTs. I sketched out the > options and respective implications below as I see them. Since I plan > to mandate one of the two based on the list feedback in the > Implementer's guide, please review carefully - your initiator, target > or NIC *may be* affected. > > I personally am leaning towards Option A because I see it's closest to > RFC 3720 semantics and would require no new conceptual additions. My vote is for option B, though we don't use the language of "No-Name iSCSI node." Why though do we have to mandate one or the other? While our target isn't one of them, I believe there are targets where TPGT would not be defined in a no-name discovery session. So I don't mind us doing something to help them. I'd just rather we permit targets that would have a TPGT available to them to use it. > Options: > > A. TPGTs are always Node-scoped. If Node name isn't specified in the > discovery Login Request PDU, TPGT is meaningless and can't be inferred > (or inferred to be invalid). > > B. TPGTs are always Node-scoped. If Node name isn't specified in the > discovery Login Request PDU, a special "No-Name" iSCSI Node is > implied. This No-Name iSCSI Node has its own TPGT numbering space - > one tag for each physically possible portal group - and thus the TPGT > can be inferred. > > Implications - > > Option A: > > 1. There can only be one no-named discovery session to a Network > Entity with a given InitiatorName-ISID combination. A new no-named > discovery session reinstates the first. If this is your current > behavior, speak up. > > 2. An initiator doing parallel discovery probing of multiple IP > addresses using a generic InitiatorName-ISID tuple may see all but one > of its probe attempts fail in each set of IP addresses hosted by one > Network Entity (if you're doing SLP/iSNS-based discovery, this may be > a no-op). > > 3. To realize the session reinstatement of a no-named discovery > session on matching InitiatorName-ISID, target CPU software may have > to be involved in Login processing for no-named discovery sessions. > Depending on your implementation, it may not all be offloaded to > hardware. > > Option B: > 1. There can be multiple no-named discovery sessions to a Network > Entity with a given InitiatorName-ISID combination - one for each TPGT > of the No-Name Node. A new no-named discovery session reinstates an > existing discovery session only if the TPGT matches. If this is your > current behavior, speak up. As above, this is our current behavior. > 2. An initiator doing parallel discovery probing of multiple IP > addresses using a generic InitiatorName-ISID tuple may have all > successful probes, but all such probes of each set of IP addresses > hosted by one Network Entity return duplicate discovery data (if > you're doing SLP/iSNS-based discovery, this may be a no-op). Well, if the probes happen sequentially, you'll get the same result of multiple overlapped data. Or if the races happen just right that the parallel probes aren't parallel as sen by the target, then you will also get this. > 3. For some implementations, it is technically feasible to offload the > login processing for a no-named discovery session. Target CPU > software is not required to be involved (although your code may have > other reasons to get involved). > > 4. Introduces a new notion of a "No-Name" iSCSI Node that must host > all physically possible portal groups. No-Name Node is however not a > full-fledged Node because TargetPortalGroupTag must not be returned - > though it can be inferred - on no-named discovery sessions per RFC > 3720, and is limited to hosting only the no-named discovery sessions. While this is true, is this really a problem? This notion does not need to manifest itself as any code or data structures. All it means is that no-named discovery sessions may have a reinstatement spam smaller than the whole network entity. Option A is just the simplest case of this. The one thing that we may wish to do is permit the TargetPortalGroupTag to be returned for no-name discovery sessions. For targets that have more than a "" TPGT for no-name discovery sessions for the whole network entity (something that isn't case A), then perhaps we should have the targets return the TPGT. Take care, Bill --Apple-Mail-8-901801579 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC8P/mDJT2Egh26K0RAoYgAJoCpR9sStHXTo/LToftbamiLOmaxQCfVIXK wOxYjdkd+DVhF9bWUZbth8A= =td00 -----END PGP SIGNATURE----- --Apple-Mail-8-901801579-- --===============0723569653== 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 --===============0723569653==-- From ips-bounces@ietf.org Wed Aug 03 13:34:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0N8l-0008Bv-C0; Wed, 03 Aug 2005 13:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0N8i-0008AP-6G; Wed, 03 Aug 2005 13:34:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02722; Wed, 3 Aug 2005 13:34:45 -0400 (EDT) Received: from mx1.netapp.com ([216.240.18.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0NfQ-0003Yt-UU; Wed, 03 Aug 2005 14:08:37 -0400 Received: from smtp2.corp.netapp.com (10.57.159.114) by mx1.netapp.com with ESMTP; 03 Aug 2005 10:34:34 -0700 X-IronPort-AV: i="3.95,164,1120460400"; d="scan'208,217"; a="239888278:sNHT28456792" Received: from svlexc03.hq.netapp.com (svlexc03.corp.netapp.com [10.57.156.149]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id j73HYXhS021813; Wed, 3 Aug 2005 10:34:33 -0700 (PDT) Received: from RTPEXC02.hq.netapp.com ([10.100.157.167]) by svlexc03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Aug 2005 10:34:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF) Date: Wed, 3 Aug 2005 13:34:32 -0400 Message-ID: Thread-Topic: [Ips] iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF) Thread-Index: AcWYUGkQgPG4BGFJS+uF/MI/kLopogAAM5TA From: "Pittman, Joseph" To: "Julian Satran" X-OriginalArrivalTime: 03 Aug 2005 17:34:33.0496 (UTC) FILETIME=[9C7A4980:01C59851] X-Spam-Score: 2.1 (++) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Cc: ips@ietf.org, ips-bounces@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1028398577==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1028398577== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59851.9BF78D02" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59851.9BF78D02 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Julo, =20 Did you mean "SCSI requires that no packets" =20 or "iSCSI requires ..." =20 I see the requirement in the iSCSI spec, but I don't think the T10 SCSI specs make any kind of multi-nexus ordering requirements of this type. If it just the iSCSI spec, and not the T10 specs, then my original objections stand... =20 If the T10 SCSI specs do, in fact, impose such a requirement, can someone point me to that? -- Joe Pittman jpittman@netapp.com =20 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Wednesday, August 03, 2005 1:26 PM To: Pittman, Joseph Cc: ips@ietf.org; ips-bounces@ietf.org Subject: Re: [Ips] iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF) =09 =09 SCSI requires that no packets pertained to the aborted tasks be received after the response to the TMF (even if they are multi-NEXI).=20 However for the case of different NEXI you may have a point in that different NEXI may not even all be iSCSI (SAM does not required this type of homogeneity).=20 For other NEXI the requirement can be weakened with a statement of "if this function is available in the transport of the other NEXI".=20 =09 =09 Julo=20 =09 =09 =09 "Pittman, Joseph" =20 Sent by: ips-bounces@ietf.org=20 03-08-05 18:31=20 To =20 cc Subject [Ips] iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF) =09 This is a question about section 4 of the iSCSI implementer's guide, draft-ietf-ips-iscsi-impl-guide-00.txt.=20 =20 In particular, steps e) and f) in the target's sequence of actions states the following:=20 =20 The Target:=20 =20 e) Takes note of last-sent StatSN on each of the connections in the iSCSI session(s) (one or more) sharing the affected tasks, and waits for acknowledgement of each StatSN (may solicit for acknowledgement by way of a NOP-In). If some tasks originate from non-iSCSI I_T_L nexuses then the means by which the target insures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).=20 =20 f) Sends the task set management response to the issuing initiator.=20 =20 =09 That is: - The target must wait until it has positive acknowledgement that all responses sent for all POTENTIALLY AFFECTED commands were received by their respective initiators - THEN the target may send the TMF response.=20 =20 =20 =20 For the purposes of this mail message, I would like to separate the=20 requirement imposed by steps e) and f), into two separate=20 sub-requirements:=20 =20 Sub-requirement 1, pertaining to: Status/Responses for iSCSI requests (including SCSI tasks) being conducted on the SAME iSCSI session as the TMF itself.=20 =20 Sub-requirement 2, pertaining to: Status/Responses for SCSI tasks being conducted on OTHER SCSI I_T_L nexuses=20 =20 =20 =20 I understand Sub-requirement 1 above. Section 4.1.3 of the implementer's guide, and especially bullet item 2 ('single ordered response flow') clearly explains why the target steps e) and f) are necessary. The iSCSI multi-connection session feature introduces the possibility of out of order arrival of responses at the initiator; it is the responsibility of the iSCSI initiator to reconstruct the in-order response stream, to satisfy the expectations of the SCSI layer.=20 =20 =09 But I cannot understand why the iSCSI specification imposes Sub-requirement 2.=20 =20 - The SCSI-2 and SCSI-3 specifications do not impose ordering constraints between two separate SCSI nexuses=20 =20 - iSCSI is merely a transport protocol for SCSI, so it seems out of place for the iSCSI spec to be imposing additional requirements on SCSI or other transports=20 =20 - It may not be possible to satisfy this sub-requirement with certain other transports=20 =20 - There are many examples of configurations with multi-pathed access from a single host system to SCSI targets using non-iSCSI transports, without the "benefit" of sub-requirement 2.=20 =20 =09 And the current version of the implementer's guide does not appear to shed light on the matter.=20 =20 Can anyone think of a justification for the inclusion of Sub-requirement 2 in the iSCSI specification? If so, should this topic be discussed in the implementer's guide?=20 =20 Thanks! -- Joe Pittman jpittman@netapp.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =09 =09 ------_=_NextPart_001_01C59851.9BF78D02 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Julo,
 
Did you mean
  "SCSI requires that no packets"
 
or
  "iSCSI requires ..."
 
I see the requirement in the iSCSI spec, but I don't think=20 the
T10 SCSI specs make any kind of multi-nexus ordering=20 requirements
of this type.  If it just the iSCSI spec, and not the T10=20 specs,
then my original objections stand...
 
If the T10 SCSI specs do, in fact, impose such = a=20 requirement, can
someone point me to that?
--
Joe Pittman
jpittman@netapp.com=
 
-----Original Message-----
From: = Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August = 03, 2005=20 1:26 PM
To: Pittman, Joseph
Cc: ips@ietf.org;=20 ips-bounces@ietf.org
Subject: Re: [Ips] iSCSI: Question = about=20 iscsi-impl-guide-00.txt, section 4 (TMF)


SCSI requires that no packets pertained to = the aborted=20 tasks be received after the response to the TMF (even if they are=20 multi-NEXI).
However for = the case of=20 different NEXI you may have a point in that different NEXI may not = even all be=20 iSCSI (SAM does not required this type of homogeneity). =
For other NEXI the requirement can be = weakened with a=20 statement of "if this function is available in the transport of the = other=20 NEXI".


Julo =


"Pittman, = Joseph"=20 <Joseph.Pittman@netapp.com>
Sent by: ips-bounces@ietf.org=20

03-08-05 18:31

To
<ips@ietf.org>=20
cc
Subject
[Ips]     =    =20 iSCSI: Question about iscsi-impl-guide-00.txt, section 4=20 (TMF)

=




This is a question about section 4 of = the iSCSI=20 implementer's
guide, draft-ietf-ips-iscsi-impl-guide-00.txt. =
 
In=20 particular, steps e) and f) in the target's sequence of = actions
states the=20 following:
 
  The Target:
  =
     e) Takes note of = last-sent=20 StatSN on each of the connections
      in the iSCSI = session(s) (one or more) sharing the affected
      = tasks,=20 and waits for acknowledgement of each StatSN (may
    =  =20 solicit for acknowledgement by way of a NOP-In). If some
  =  =20   tasks originate from non-iSCSI I_T_L nexuses then the = means
 =20     by which the target insures that all affected tasks=20 have
      returned their status to the initiator = are=20 defined by the
      specific non-iSCSI transport=20 protocol(s).
 
     f) Sends the task = set management=20 response to the issuing
      =  initiator.=20
 

That=20 is:
- The target must wait until it has positive acknowledgement = that=20 all
 responses sent for all POTENTIALLY AFFECTED commands were = received by
 their respective initiators
- THEN the target = may send=20 the TMF response.
 
 
 
For the purposes of this mail message, I = would like=20 to separate the
requirement imposed=20 by steps e) and f), into two separate
sub-requirements:
  =
Sub-requirement 1, pertaining=20 to:
 Status/Responses for iSCSI requests (including SCSI = tasks)=20 being
 conducted on the SAME iSCSI session as the TMF = itself.=20
 
Sub-requirement 2, pertaining to:
 Status/Responses = for SCSI=20 tasks being conducted on OTHER SCSI
 I_T_L nexuses =
 
 
 
I = understand=20 Sub-requirement 1 above.  Section 4.1.3 of the = implementer's
guide,=20 and especially bullet item 2 ('single ordered response = flow')
clearly=20 explains why the target steps e) and f) are necessary.
The iSCSI=20 multi-connection session feature introduces the possibility
of out = of order=20 arrival of responses at the initiator; it is the
responsibility of = the=20 iSCSI initiator to reconstruct the in-order
response stream, to = satisfy the=20 expectations of the SCSI layer.
 =20

But I cannot understand = why the iSCSI=20 specification imposes
Sub-requirement 2.
 
- The = SCSI-2 and=20 SCSI-3 specifications do not impose ordering
 constraints = between two=20 separate SCSI nexuses
  =
- iSCSI is merely a transport protocol = for SCSI, so=20 it seems
 out of place for the iSCSI spec to be imposing=20 additional
 requirements on SCSI or other transports =
 
- It = may not be=20 possible to satisfy this sub-requirement with
 certain other=20 transports
 
- There are many examples of configurations with multi-pathed = access
 from a single host system to SCSI targets using = non-iSCSI=20 transports,
 without the "benefit" of sub-requirement = 2.=20
 

And the=20 current version of the implementer's guide does not appear
to shed = light on=20 the matter.
 
Can anyone think of a justification for the inclusion=20 of
Sub-requirement 2 in the iSCSI specification?  If so, = should=20 this
topic be discussed in the implementer's guide? =
 
Thanks!
--
Joe=20 Pittman
jpittman@netapp.com_______________________________________________
Ips = mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

=00 ------_=_NextPart_001_01C59851.9BF78D02-- --===============1028398577== 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 --===============1028398577==-- From ips-bounces@ietf.org Wed Aug 03 16:31:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Pu9-0008UY-FW; Wed, 03 Aug 2005 16:31:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Pu7-0008UT-Ij for ips@megatron.ietf.org; Wed, 03 Aug 2005 16:31:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18130 for ; Wed, 3 Aug 2005 16:31:53 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0QQk-00043P-Vq for ips@ietf.org; Wed, 03 Aug 2005 17:05:46 -0400 Received: from [192.168.1.163] (unknown [12.7.171.135]) by mononoke.wasabisystems.com (Postfix) with ESMTP id B18648707A for ; Wed, 3 Aug 2005 16:31:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) Message-Id: To: IPS From: William Studenmund Date: Wed, 3 Aug 2005 13:31:07 -0700 X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ips] New thought for draft-ietf-ips-iscsi-impl-guide-00.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: , Content-Type: multipart/mixed; boundary="===============1135138637==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1135138637== Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-9-912462808" --Apple-Mail-9-912462808 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit One thing I've remembered I wanted to note is that initiators should prepare themselves for DNS names showing up multiple times in SendTargets discovery. The reason for this is that a TargetAddress value does not indicate if a DNS address is IPv4 or IPv6. It is possible for a DNS name to map to both an A and AAAA record. If the target's configuration explicitly indicates IPv4 vs IPv6, it is possible to have different portals on the v4 and v6 addresses for a DNS name. It is also possible for the different portals to report the same DNS name and also be in different portal groups. In this case, the TPGT reported for each would differ. Take care, Bill --Apple-Mail-9-912462808 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC8SmQDJT2Egh26K0RAjtGAJ0VtF5DOndOTQu5Tec5ja0zdRrtDACcCu/d 7Pd4F7oHlZodeaQAQvR61U0= =6HNa -----END PGP SIGNATURE----- --Apple-Mail-9-912462808-- --===============1135138637== 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 --===============1135138637==-- From ips-bounces@ietf.org Wed Aug 03 20:36:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0TiU-0006IF-BD; Wed, 03 Aug 2005 20:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0TiS-0006I7-8t for ips@megatron.ietf.org; Wed, 03 Aug 2005 20:36:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29096 for ; Wed, 3 Aug 2005 20:36:04 -0400 (EDT) Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0UFC-0003zL-VU for ips@ietf.org; Wed, 03 Aug 2005 21:09:59 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel7.hp.com (Postfix) with ESMTP id BC07918C80 for ; Wed, 3 Aug 2005 20:36:02 -0400 (EDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.53]) by rosemail.rose.hp.com (Postfix) with ESMTP id E5E478253 for ; Wed, 3 Aug 2005 13:46:03 -0700 (PDT) Message-ID: <42F162EB.6010903@rose.hp.com> Date: Wed, 03 Aug 2005 17:35:55 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] iSCSI: Question about iscsi-impl-guide-00.txt, section 4 (TMF) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.0 (+) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Joe, > - The target must wait until it has positive acknowledgement that all > responses sent for all POTENTIALLY AFFECTED commands were received by > their respective initiators Only for iSCSI-based I_T_L nexuses. > For the purposes of this mail message, I would like to separate the > requirement imposed by steps e) and f), into two separate > sub-requirements: There is also the intermediate "requirement": Sub-requirement 1.5: Status/Responses for SCSI tasks being conducted on OTHER iSCSI I_T_L nexuses But the caveat is that the "requirement" levels vary for iSCSI & non-iSCSI transports. In implementation terms, the RFC 3720 text (also in Implementer's guide): "If some tasks originate from non-iSCSI I_T_L nexuses then the means by which the target insures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s)." is, IMO, fairly benign, meant to address the obvious question of "what do we do with non-iSCSI nexuses?" It is only saying that any task statuses have to be returned to respective initiators before the issuing initiator is sent the TMF Response - it isn't suggesting waiting for status acknowledgements across the board for all transports. The "MUST wait for StatSN ack" rule obviously applies only to I_T nexuses of iSCSI transport type. In addition, "the means" of "returning the status" are left to other transport protocol implementations as well - it may be a simple inter-layer enqueue operation in some implementations. > - The SCSI-2 and SCSI-3 specifications do not impose ordering > constraints between two separate SCSI nexuses Note that iSCSI only specifies this ordering constraint across iSCSI sessions for "iSCSI reasons". It is not a SCSI nexus constraint in that SCSI layer is privy to this iSCSI behavior. > - iSCSI is merely a transport protocol for SCSI, so it seems > out of place for the iSCSI spec to be imposing additional > requirements on SCSI or other transports > > - It may not be possible to satisfy this sub-requirement with > certain other transports As commented above, RFC 3720 text is neither imposing requirements on other transports nor the SCSI layer. > And the current version of the implementer's guide does not appear > to shed light on the matter. You're right, not completely. The "iSCSI reasons" for this behavior are tied to the "single ordered response flow" principle. There are two aspects of single ordered response flow - 1) The TMF response must not pass the affected task responses (on the TMF-issuing session). I think the current draft text makes this case. 2) The UA notification (set due to Clear Task Set) must not pass the task responses (on all the iSCSI sessions accessing the LU). More on this below. SAM requires Clear Task Set to trigger a UA on all I_T_L nexuses. Once an initiator is notified of such an UA, the application client on the receiving initiator is required to clear its task state (clause 5.5) for each task in the task set. It would thus be inappropriate to deliver a SCSI Response for a task after the task state is cleared on the initiator, i.e. after the UA is notified. What #1 & #2 above imply is that the current text is not quite complete in that it says nothing about how iSCSI should deal with SCSI task reponses being handed down to it *after* the TMF response (the first SCSI task response carries the UA notification). We should have text that mandates that SCSI reponses must be held back at the iSCSI layer until the affected task response acks are received. IOW, the TMF reponse and the "unaffected" task responses (the first of which presumably carrying the UA) are all "released" once the affected StatSN acks are received. Once we agree on this, I can propose specific text under a separate cover to address the issue. Thanks! Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Pittman, Joseph wrote: > > This is a question about section 4 of the iSCSI implementer's > guide, draft-ietf-ips-iscsi-impl-guide-00.txt. > > In particular, steps e) and f) in the target's sequence of actions > states the following: > > The Target: > > e) Takes note of last-sent StatSN on each of the connections > in the iSCSI session(s) (one or more) sharing the affected > tasks, and waits for acknowledgement of each StatSN (may > solicit for acknowledgement by way of a NOP-In). If some > tasks originate from non-iSCSI I_T_L nexuses then the means > by which the target insures that all affected tasks have > returned their status to the initiator are defined by the > specific non-iSCSI transport protocol(s). > > f) Sends the task set management response to the issuing > initiator. > > > That is: > - The target must wait until it has positive acknowledgement that all > responses sent for all POTENTIALLY AFFECTED commands were received by > their respective initiators > - THEN the target may send the TMF response. > > > > For the purposes of this mail message, I would like to separate the > requirement imposed by steps e) and f), into two separate > sub-requirements: > > Sub-requirement 1, pertaining to: > Status/Responses for iSCSI requests (including SCSI tasks) being > conducted on the SAME iSCSI session as the TMF itself. > > Sub-requirement 2, pertaining to: > Status/Responses for SCSI tasks being conducted on OTHER SCSI > I_T_L nexuses > > > > I understand Sub-requirement 1 above. Section 4.1.3 of the implementer's > guide, and especially bullet item 2 ('single ordered response flow') > clearly explains why the target steps e) and f) are necessary. > The iSCSI multi-connection session feature introduces the possibility > of out of order arrival of responses at the initiator; it is the > responsibility of the iSCSI initiator to reconstruct the in-order > response stream, to satisfy the expectations of the SCSI layer. > > > But I cannot understand why the iSCSI specification imposes > Sub-requirement 2. > > - The SCSI-2 and SCSI-3 specifications do not impose ordering > constraints between two separate SCSI nexuses > > - iSCSI is merely a transport protocol for SCSI, so it seems > out of place for the iSCSI spec to be imposing additional > requirements on SCSI or other transports > > - It may not be possible to satisfy this sub-requirement with > certain other transports > > - There are many examples of configurations with multi-pathed access > from a single host system to SCSI targets using non-iSCSI transports, > without the "benefit" of sub-requirement 2. > > > And the current version of the implementer's guide does not appear > to shed light on the matter. > > Can anyone think of a justification for the inclusion of > Sub-requirement 2 in the iSCSI specification? If so, should this > topic be discussed in the implementer's guide? > > Thanks! > -- > Joe Pittman > jpittman@netapp.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 03 20:58:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0U4R-0005LZ-DT; Wed, 03 Aug 2005 20:58:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0U4O-0005K7-Kx for ips@megatron.ietf.org; Wed, 03 Aug 2005 20:58:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29976 for ; Wed, 3 Aug 2005 20:58:47 -0400 (EDT) Received: from atlrel8.hp.com ([156.153.255.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0UbB-0004ms-M4 for ips@ietf.org; Wed, 03 Aug 2005 21:32:42 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel8.hp.com (Postfix) with ESMTP id 44925C707 for ; Wed, 3 Aug 2005 20:58:47 -0400 (EDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.53]) by rosemail.rose.hp.com (Postfix) with ESMTP id 72F928253 for ; Wed, 3 Aug 2005 14:08:48 -0700 (PDT) Message-ID: <42F16848.10706@rose.hp.com> Date: Wed, 03 Aug 2005 17:58:48 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS Subject: Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> <9a00dc707c09c8d4e58ac7f8a9f980fb@wasabisystems.com> <5bed23bfdf7ace05d6e538adb57c0381@wasabisystems.com> <42E81C7E.5020907@rose.hp.com> <9e8ad9858bd06593b8d2ecde86f96440@wasabisystems.com> <42EAD17E.5040703@rose.hp.com> <02bcc5c4eb5c765739541c226dc4eca1@wasabisystems.com> In-Reply-To: <02bcc5c4eb5c765739541c226dc4eca1@wasabisystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bill, > Why though do we have to mandate one or the other? That is a good question. I thought this was found to be an interoperability issue in the past, as evidenced by multiple email threads on this topic. And that's why Bob Russell brought this to this forum again to document and be done with it. Option A, BTW, was the earlier list "conclusion" (I'd stay away from "consensus" for David hasn't called it) as far as I can tell from previous email threads. As you suggest, we can say: a) some targets do no-name discovery session reinstatements and some don't, on matching InitiatorName-ISID; b) some targets return TPGT on no-name discovery sessions and some don't. But I thought that was the problem we're trying to address with the guide. I suggest it is time to call the consensus on the topic and move on. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com William Studenmund wrote: > On Jul 29, 2005, at 6:01 PM, Mallikarjun C. wrote: > >> OK, I see two options in dealing with TPGTs. I sketched out the >> options and respective implications below as I see them. Since I plan >> to mandate one of the two based on the list feedback in the >> Implementer's guide, please review carefully - your initiator, target >> or NIC *may be* affected. >> >> I personally am leaning towards Option A because I see it's closest to >> RFC 3720 semantics and would require no new conceptual additions. > > > My vote is for option B, though we don't use the language of "No-Name > iSCSI node." > > Why though do we have to mandate one or the other? While our target > isn't one of them, I believe there are targets where TPGT would not be > defined in a no-name discovery session. So I don't mind us doing > something to help them. I'd just rather we permit targets that would > have a TPGT available to them to use it. > >> Options: >> >> A. TPGTs are always Node-scoped. If Node name isn't specified in the >> discovery Login Request PDU, TPGT is meaningless and can't be inferred >> (or inferred to be invalid). >> >> B. TPGTs are always Node-scoped. If Node name isn't specified in the >> discovery Login Request PDU, a special "No-Name" iSCSI Node is >> implied. This No-Name iSCSI Node has its own TPGT numbering space - >> one tag for each physically possible portal group - and thus the TPGT >> can be inferred. >> >> Implications - >> >> Option A: >> >> 1. There can only be one no-named discovery session to a Network >> Entity with a given InitiatorName-ISID combination. A new no-named >> discovery session reinstates the first. If this is your current >> behavior, speak up. >> >> 2. An initiator doing parallel discovery probing of multiple IP >> addresses using a generic InitiatorName-ISID tuple may see all but one >> of its probe attempts fail in each set of IP addresses hosted by one >> Network Entity (if you're doing SLP/iSNS-based discovery, this may be >> a no-op). >> >> 3. To realize the session reinstatement of a no-named discovery >> session on matching InitiatorName-ISID, target CPU software may have >> to be involved in Login processing for no-named discovery sessions. >> Depending on your implementation, it may not all be offloaded to >> hardware. >> >> Option B: >> 1. There can be multiple no-named discovery sessions to a Network >> Entity with a given InitiatorName-ISID combination - one for each TPGT >> of the No-Name Node. A new no-named discovery session reinstates an >> existing discovery session only if the TPGT matches. If this is your >> current behavior, speak up. > > > As above, this is our current behavior. > >> 2. An initiator doing parallel discovery probing of multiple IP >> addresses using a generic InitiatorName-ISID tuple may have all >> successful probes, but all such probes of each set of IP addresses >> hosted by one Network Entity return duplicate discovery data (if >> you're doing SLP/iSNS-based discovery, this may be a no-op). > > > Well, if the probes happen sequentially, you'll get the same result of > multiple overlapped data. Or if the races happen just right that the > parallel probes aren't parallel as sen by the target, then you will also > get this. > >> 3. For some implementations, it is technically feasible to offload the >> login processing for a no-named discovery session. Target CPU >> software is not required to be involved (although your code may have >> other reasons to get involved). >> >> 4. Introduces a new notion of a "No-Name" iSCSI Node that must host >> all physically possible portal groups. No-Name Node is however not a >> full-fledged Node because TargetPortalGroupTag must not be returned - >> though it can be inferred - on no-named discovery sessions per RFC >> 3720, and is limited to hosting only the no-named discovery sessions. > > > While this is true, is this really a problem? This notion does not need > to manifest itself as any code or data structures. All it means is that > no-named discovery sessions may have a reinstatement spam smaller than > the whole network entity. Option A is just the simplest case of this. > > The one thing that we may wish to do is permit the TargetPortalGroupTag > to be returned for no-name discovery sessions. For targets that have > more than a "" TPGT for no-name discovery sessions for the whole network > entity (something that isn't case A), then perhaps we should have the > targets return the TPGT. > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 04 02:16:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Z20-0003R3-21; Thu, 04 Aug 2005 02:16:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Z1t-0003Qs-Pq for ips@megatron.ietf.org; Thu, 04 Aug 2005 02:16:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26903 for ; Thu, 4 Aug 2005 02:16:31 -0400 (EDT) Received: from relay1.mail.twtelecom.net ([216.136.102.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0ZYg-00074s-HI for ips@ietf.org; Thu, 04 Aug 2005 02:50:26 -0400 Received: from saturn.p3corpnet.pivot3.com (207-114-252-60.gen.twtelecom.net [207.114.252.60]) by relay1.mail.twtelecom.net (Postfix) with ESMTP id 00C7FC7B for ; Thu, 4 Aug 2005 01:13:57 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Re: ISID and Discovery Re:draft-ietf-ips-iscsi-impl-guide-00.txt Date: Thu, 4 Aug 2005 01:16:14 -0500 Message-ID: Thread-Topic: [Ips] Re: ISID and Discovery Re:draft-ietf-ips-iscsi-impl-guide-00.txt Thread-Index: AcWYj8hsHI1P8sTRSm272371KorKEQAK3Crw From: "Galloway, Bill" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: quoted-printable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I am very much in favor of allowing both. I can see why some targets do not want to implement the more complicated option B. For those targets that have multiple independent ports for fault tolerance, option A is nearly impossible to implement and that target would take on the burden of option B. Bill Galloway > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Mallikarjun C. > Sent: Wednesday, August 03, 2005 7:59 PM > To: IPS > Subject: Re: [Ips] Re: ISID and Discovery=20 > Re:draft-ietf-ips-iscsi-impl-guide-00.txt >=20 > Bill, >=20 > > Why though do we have to mandate one or the other? >=20 > That is a good question. I thought this was found to be an=20 > interoperability issue in the past, as evidenced by multiple email=20 > threads on this topic. And that's why Bob Russell brought=20 > this to this=20 > forum again to document and be done with it. >=20 > Option A, BTW, was the earlier list "conclusion" (I'd stay away from=20 > "consensus" for David hasn't called it) as far as I can tell from=20 > previous email threads. >=20 > As you suggest, we can say: > a) some targets do no-name discovery session reinstatements and some=20 > don't, on matching InitiatorName-ISID; > b) some targets return TPGT on no-name discovery sessions and=20 > some don't. >=20 > But I thought that was the problem we're trying to address=20 > with the guide. >=20 > I suggest it is time to call the consensus on the topic and move on. >=20 >=20 > Mallikarjun >=20 > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com >=20 >=20 > William Studenmund wrote: > > On Jul 29, 2005, at 6:01 PM, Mallikarjun C. wrote: > >=20 > >> OK, I see two options in dealing with TPGTs. I sketched out the=20 > >> options and respective implications below as I see them. =20 > Since I plan=20 > >> to mandate one of the two based on the list feedback in the=20 > >> Implementer's guide, please review carefully - your=20 > initiator, target=20 > >> or NIC *may be* affected. > >> > >> I personally am leaning towards Option A because I see=20 > it's closest to=20 > >> RFC 3720 semantics and would require no new conceptual additions. > >=20 > >=20 > > My vote is for option B, though we don't use the language=20 > of "No-Name=20 > > iSCSI node." > >=20 > > Why though do we have to mandate one or the other? While our target=20 > > isn't one of them, I believe there are targets where TPGT=20 > would not be=20 > > defined in a no-name discovery session. So I don't mind us doing=20 > > something to help them. I'd just rather we permit targets=20 > that would=20 > > have a TPGT available to them to use it. > >=20 > >> Options: > >> > >> A. TPGTs are always Node-scoped. If Node name isn't=20 > specified in the=20 > >> discovery Login Request PDU, TPGT is meaningless and can't=20 > be inferred=20 > >> (or inferred to be invalid). > >> > >> B. TPGTs are always Node-scoped. If Node name isn't=20 > specified in the=20 > >> discovery Login Request PDU, a special "No-Name" iSCSI Node is=20 > >> implied. This No-Name iSCSI Node has its own TPGT=20 > numbering space -=20 > >> one tag for each physically possible portal group - and=20 > thus the TPGT=20 > >> can be inferred. > >> > >> Implications - > >> > >> Option A: > >> > >> 1. There can only be one no-named discovery session to a Network=20 > >> Entity with a given InitiatorName-ISID combination. A new no-named=20 > >> discovery session reinstates the first. If this is your current=20 > >> behavior, speak up. > >> > >> 2. An initiator doing parallel discovery probing of multiple IP=20 > >> addresses using a generic InitiatorName-ISID tuple may see=20 > all but one=20 > >> of its probe attempts fail in each set of IP addresses=20 > hosted by one=20 > >> Network Entity (if you're doing SLP/iSNS-based discovery,=20 > this may be=20 > >> a no-op). > >> > >> 3. To realize the session reinstatement of a no-named discovery=20 > >> session on matching InitiatorName-ISID, target CPU=20 > software may have=20 > >> to be involved in Login processing for no-named discovery=20 > sessions. =20 > >> Depending on your implementation, it may not all be offloaded to=20 > >> hardware. > >> > >> Option B: > >> 1. There can be multiple no-named discovery sessions to a Network=20 > >> Entity with a given InitiatorName-ISID combination - one=20 > for each TPGT=20 > >> of the No-Name Node. A new no-named discovery session=20 > reinstates an=20 > >> existing discovery session only if the TPGT matches. If=20 > this is your=20 > >> current behavior, speak up. > >=20 > >=20 > > As above, this is our current behavior. > >=20 > >> 2. An initiator doing parallel discovery probing of multiple IP=20 > >> addresses using a generic InitiatorName-ISID tuple may have all=20 > >> successful probes, but all such probes of each set of IP addresses=20 > >> hosted by one Network Entity return duplicate discovery data (if=20 > >> you're doing SLP/iSNS-based discovery, this may be a no-op). > >=20 > >=20 > > Well, if the probes happen sequentially, you'll get the=20 > same result of=20 > > multiple overlapped data. Or if the races happen just right=20 > that the=20 > > parallel probes aren't parallel as sen by the target, then=20 > you will also=20 > > get this. > >=20 > >> 3. For some implementations, it is technically feasible to=20 > offload the=20 > >> login processing for a no-named discovery session. Target CPU=20 > >> software is not required to be involved (although your=20 > code may have=20 > >> other reasons to get involved). > >> > >> 4. Introduces a new notion of a "No-Name" iSCSI Node that=20 > must host=20 > >> all physically possible portal groups. No-Name Node is=20 > however not a=20 > >> full-fledged Node because TargetPortalGroupTag must not be=20 > returned -=20 > >> though it can be inferred - on no-named discovery sessions per RFC=20 > >> 3720, and is limited to hosting only the no-named=20 > discovery sessions. > >=20 > >=20 > > While this is true, is this really a problem? This notion=20 > does not need=20 > > to manifest itself as any code or data structures. All it=20 > means is that=20 > > no-named discovery sessions may have a reinstatement spam=20 > smaller than=20 > > the whole network entity. Option A is just the simplest=20 > case of this. > >=20 > > The one thing that we may wish to do is permit the=20 > TargetPortalGroupTag=20 > > to be returned for no-name discovery sessions. For targets=20 > that have=20 > > more than a "" TPGT for no-name discovery sessions for the=20 > whole network=20 > > entity (something that isn't case A), then perhaps we=20 > should have the=20 > > targets return the TPGT. > >=20 > > Take care, > >=20 > > Bill >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 04 13:51:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jsF-00006d-9L; Thu, 04 Aug 2005 13:51:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0jsD-0008Ue-NB for ips@megatron.ietf.org; Thu, 04 Aug 2005 13:51:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26845 for ; Thu, 4 Aug 2005 13:51:16 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0kP3-0002g0-5A for ips@ietf.org; Thu, 04 Aug 2005 14:25:20 -0400 Received: from [192.168.1.163] (unknown [12.7.171.135]) by mononoke.wasabisystems.com (Postfix) with ESMTP id A357A8706C; Thu, 4 Aug 2005 13:50:55 -0400 (EDT) In-Reply-To: <42F16848.10706@rose.hp.com> References: <42D80408.1060108@rose.hp.com> <42DD9271.4010706@rose.hp.com> <9a00dc707c09c8d4e58ac7f8a9f980fb@wasabisystems.com> <5bed23bfdf7ace05d6e538adb57c0381@wasabisystems.com> <42E81C7E.5020907@rose.hp.com> <9e8ad9858bd06593b8d2ecde86f96440@wasabisystems.com> <42EAD17E.5040703@rose.hp.com> <02bcc5c4eb5c765739541c226dc4eca1@wasabisystems.com> <42F16848.10706@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <014d1d1e0e2844a34009de9ed227ca14@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Re: ISID and Discovery Re: draft-ietf-ips-iscsi-impl-guide-00.txt Date: Thu, 4 Aug 2005 10:50:41 -0700 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2074267319==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============2074267319== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4-989236660" Content-Transfer-Encoding: 7bit --Apple-Mail-4-989236660 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 3, 2005, at 5:58 PM, Mallikarjun C. wrote: > Bill, > > > Why though do we have to mandate one or the other? > > That is a good question. I thought this was found to be an > interoperability issue in the past, as evidenced by multiple email > threads on this topic. And that's why Bob Russell brought this to > this forum again to document and be done with it. I guess my hope was to come up with one behavior/description which includes both cases. So we have one understanding, one rule, and different targets could choose different behaviors within this one rule. > Option A, BTW, was the earlier list "conclusion" (I'd stay away from > "consensus" for David hasn't called it) as far as I can tell from > previous email threads. I'll be honest. I was part of that "conclusion" and I overlooked the TPGT aspect of it. :-) > As you suggest, we can say: > a) some targets do no-name discovery session reinstatements and some > don't, on matching InitiatorName-ISID; > b) some targets return TPGT on no-name discovery sessions and some > don't. > > But I thought that was the problem we're trying to address with the > guide. I'm sorry, my original comment was aimed more at the thought that we had to make a tradeoff with one idea vs the other. I think we can find a common ground that will encompass all behaviors. My thought is to refine what you say above. On a no-name discovery session, if a target does not return a TPGT, then the TPGT should be taken as "" or NULL (as you suggested). Then all targets do session reinstatement on no-name discovery sessions against other sessions with matching InitiatorName-ISID-NULL_TargetName-TPGT. So all portals that don't return a TPGT will reinstate with each other. All portals that return TPGT 0 will reinstate with each other, and so on. In essence we add "" or NULL to the TPGT space for discovery sessions, and the ISID rule applies. Thus an initiator can figure out what the target is doing and it should not be surprised about what is happening. I think letting/requiring targets to send a TPGT when they have a TPGT in mind (not "" or NULL) is an important change. Without it, the initiator would be shooting blind and could have little clue as to what the target is doing. I think that's bad. So bad that if we don't permit/require sending a TPGT when the target is acting like it is not "" or NULL, then I think we should go with option A. Otherwise I feel we would have a shooting-in-the-dark situation which feels very messy to me. Take care, Bill --Apple-Mail-4-989236660 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC8lV3DJT2Egh26K0RAk5AAKCGdGuoA/eOoFv4Wtm+j6wN9Sr8vwCghOqx IRtsot5ioUwfRe3T++TO6A8= =TvB8 -----END PGP SIGNATURE----- --Apple-Mail-4-989236660-- --===============2074267319== 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 --===============2074267319==-- From ips-bounces@ietf.org Thu Aug 04 21:46:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0rHy-0005NS-7Y; Thu, 04 Aug 2005 21:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0rHw-0005Me-OZ for ips@megatron.ietf.org; Thu, 04 Aug 2005 21:46:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23280 for ; Thu, 4 Aug 2005 21:46:18 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([216.148.227.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0row-00066k-6w for ips@ietf.org; Thu, 04 Aug 2005 22:20:26 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc11) with SMTP id <2005080501460901300drrjue>; Fri, 5 Aug 2005 01:46:09 +0000 Message-ID: <000c01c5995f$73eb4af0$03031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Thu, 4 Aug 2005 21:46:08 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.6 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.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: , Content-Type: multipart/mixed; boundary="===============1126505949==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1126505949== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C5993D.EC0E6BB0" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C5993D.EC0E6BB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In my mind, Section 5.1 ITT wording is in question: Section 10.19 in [RFC3720] mentions this in passing but noted=20 here again for making it obvious. An ITT value of 0xffffffff is=20 reserved and MUST NOT be used by the initiator. The only=20 instance it may be seen on the wire is in a target-initiated=20 NOP-In PDU (and the initiator response to that PDU if=20 necessary). If taken in the context of 10.19, it doesn't make sense since the = initiator does not issue NOP-In and hence the 2nd sentence seems out of = place. Or --- Are you saying that the following is being withdrawn from the RFC? 10.18.1. Initiator Task Tag ....... Otherwise, the Initiator Task Tag MUST be set to 0xffffffff. ......... If the Initiator Task Tag contains 0xffffffff, the I bit MUST be set to 1 and the CmdSN is not advanced after this PDU is sent. ------=_NextPart_000_0009_01C5993D.EC0E6BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In my mind, Section 5.1 ITT wording is in question:

Section 10.19 in [RFC3720] mentions this in passing but noted =
here again=20 for making it obvious.  An ITT value of 0xffffffff is
reserved = and MUST=20 NOT be used by the initiator.  The only
instance it may be seen = on the=20 wire is in a target-initiated
NOP-In PDU (and the initiator response = to that=20 PDU if
necessary).

If taken in the context of 10.19, it doesn't make = sense since=20 the initiator does not issue NOP-In and hence the 2nd sentence seems out = of=20 place.

Or ---

Are you saying that the following is = being=20 withdrawn from the RFC?

10.18.1.  Initiator Task Tag

   .......  Otherwise, the Initiator=20 Task Tag MUST be set to 0xffffffff.

   .........

   If the Initiator Task Tag contains = 0xffffffff, the=20 I bit MUST be set
   to 1 and the CmdSN is not advanced = after this=20 PDU is sent.

------=_NextPart_000_0009_01C5993D.EC0E6BB0-- --===============1126505949== 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 --===============1126505949==-- From ips-bounces@ietf.org Fri Aug 05 12:15:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E14oe-0005Lw-Up; Fri, 05 Aug 2005 12:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E14oc-0005KB-Vt for ips@megatron.ietf.org; Fri, 05 Aug 2005 12:12:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18329 for ; Fri, 5 Aug 2005 12:12:55 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E15Lj-0003GK-D5 for ips@ietf.org; Fri, 05 Aug 2005 12:47:12 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 762068707A; Fri, 5 Aug 2005 12:12:47 -0400 (EDT) In-Reply-To: <000c01c5995f$73eb4af0$03031eac@ivivity.com> References: <000c01c5995f$73eb4af0$03031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <711d160cd12ec246f5ced91daaf49bb8@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Date: Fri, 5 Aug 2005 09:12:41 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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="===============0286023807==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0286023807== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-1069757159" Content-Transfer-Encoding: 7bit --Apple-Mail-1-1069757159 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Aug 4, 2005, at 6:46 PM, Eddy Quicksall wrote: > In my mind, Section 5.1 ITT wording is in question: > > Section 10.19 in [RFC3720] mentions this in passing but noted > here again for making it obvious.=A0 An ITT value of 0xffffffff is > reserved and MUST NOT be used by the initiator.=A0 The only > instance it may be seen on the wire is in a target-initiated > NOP-In PDU (and the initiator response to that PDU if > necessary). > > If taken in the context of 10.19, it doesn't make sense since the=20 > initiator does not issue NOP-In and hence the 2nd sentence seems out=20= > of place. Do you mean the third sentence? The point is that if the initiator ever uses an ITT of 0xffffffff,=20 there is no way to tell a target-initiated NOP-IN from a response to an=20= initiator-generated one. > Or --- > > Are you saying that the following is being withdrawn from the RFC? > > 10.18.1.=A0 Initiator Task Tag > > =A0=A0 .......=A0 Otherwise, the Initiator Task=A0Tag MUST be set to=20= > 0xffffffff. > > =A0=A0 ......... > > =A0=A0 If the Initiator Task Tag contains 0xffffffff, the I bit MUST = be set > =A0=A0 to 1 and the CmdSN is not advanced after this PDU is sent. No, that's the whole point. That's the "Initiator response" PDU. I think the confusion is that setting the ITT field to 0xffffffff is=20 not "using" it. At least not as I understand it. "Using" an ITT is=20 having a task in the initiator that has an ITT with that value. Thus we=20= are saying that the initiator MUST never start a task that as an ITT of=20= 0xffffffff. Put another way, the "pick an ITT" function in the initiator must never=20= return 0xffffffff. Does that make things clearer? Take care, Bill --Apple-Mail-1-1069757159 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC84//DJT2Egh26K0RAqhaAJ4wN/Yg9eBgtqnIlnncq8qA7uuSUgCeLhOv aefqod5zQQLAg55RiOFh7HI= =dvqv -----END PGP SIGNATURE----- --Apple-Mail-1-1069757159-- --===============0286023807== 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 --===============0286023807==-- From ips-bounces@ietf.org Fri Aug 05 17:43:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E19yV-0003wS-VH; Fri, 05 Aug 2005 17:43:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E19yU-0003vn-BG for ips@megatron.ietf.org; Fri, 05 Aug 2005 17:43:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05306 for ; Fri, 5 Aug 2005 17:43:27 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1AVe-0004HF-NW for ips@ietf.org; Fri, 05 Aug 2005 18:17:46 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc14) with SMTP id <2005080521431401400d1hn4e>; Fri, 5 Aug 2005 21:43:19 +0000 Message-ID: <001401c59a06$b23360c0$03031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <000c01c5995f$73eb4af0$03031eac@ivivity.com> <711d160cd12ec246f5ced91daaf49bb8@wasabisystems.com> Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Date: Fri, 5 Aug 2005 17:43:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Actually I know what the paragraph is trying to say but I think it is not worded clearly. Also, paragraphs 10.18 and 10.19 are very clear on this subject so I also wonder why it has to be explained again. Explaining again in unclear terms can imply unwanted understanding. "An ITT value of ... NOT be used by the initiator" ... paragraph 10.19 is talking about Nop-In's and the initiator does not send NOP-In's. Hence one wonders what this is trying to say. If one thinks of this as a reference to 10.18 then the ffffffff contradicts the RFC. Hence the mind shifts back and forth trying to figure out why this paragraph is even here. If you guys think it is clear after reviewing it, then I'll accept that. Eddy ----- Original Message ----- From: "William Studenmund" To: "Eddy Quicksall" Cc: Sent: Friday, August 05, 2005 12:12 PM Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] On Aug 4, 2005, at 6:46 PM, Eddy Quicksall wrote: > In my mind, Section 5.1 ITT wording is in question: > > Section 10.19 in [RFC3720] mentions this in passing but noted > here again for making it obvious. An ITT value of 0xffffffff is > reserved and MUST NOT be used by the initiator. The only > instance it may be seen on the wire is in a target-initiated > NOP-In PDU (and the initiator response to that PDU if > necessary). > > If taken in the context of 10.19, it doesn't make sense since the > initiator does not issue NOP-In and hence the 2nd sentence seems out > of place. Do you mean the third sentence? The point is that if the initiator ever uses an ITT of 0xffffffff, there is no way to tell a target-initiated NOP-IN from a response to an initiator-generated one. > Or --- > > Are you saying that the following is being withdrawn from the RFC? > > 10.18.1. Initiator Task Tag > > ....... Otherwise, the Initiator Task Tag MUST be set to > 0xffffffff. > > ......... > > If the Initiator Task Tag contains 0xffffffff, the I bit MUST be set > to 1 and the CmdSN is not advanced after this PDU is sent. No, that's the whole point. That's the "Initiator response" PDU. I think the confusion is that setting the ITT field to 0xffffffff is not "using" it. At least not as I understand it. "Using" an ITT is having a task in the initiator that has an ITT with that value. Thus we are saying that the initiator MUST never start a task that as an ITT of 0xffffffff. Put another way, the "pick an ITT" function in the initiator must never return 0xffffffff. Does that make things clearer? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Aug 05 20:13:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1CJf-00035e-Ud; Fri, 05 Aug 2005 20:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1CJe-00035Q-7g for ips@megatron.ietf.org; Fri, 05 Aug 2005 20:13:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11743 for ; Fri, 5 Aug 2005 20:13:28 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1Cqp-0007Ki-6S for ips@ietf.org; Fri, 05 Aug 2005 20:47:48 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 61BF587081; Fri, 5 Aug 2005 20:13:15 -0400 (EDT) In-Reply-To: <001401c59a06$b23360c0$03031eac@ivivity.com> References: <000c01c5995f$73eb4af0$03031eac@ivivity.com> <711d160cd12ec246f5ced91daaf49bb8@wasabisystems.com> <001401c59a06$b23360c0$03031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <2565d931498543a740f1c8d4f34d00b5@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Date: Fri, 5 Aug 2005 17:13:06 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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="===============0590402471==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0590402471== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--1048901239" Content-Transfer-Encoding: 7bit --Apple-Mail-2--1048901239 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 5, 2005, at 2:43 PM, Eddy Quicksall wrote: > Actually I know what the paragraph is trying to say but I think it is > not worded clearly. Also, paragraphs 10.18 and 10.19 are very clear on > this subject so I also wonder why it has to be explained again. > Explaining again in unclear terms can imply unwanted understanding. > > "An ITT value of ... NOT be used by the initiator" ... paragraph 10.19 > is talking about Nop-In's and the initiator does not send NOP-In's. > Hence one wonders what this is trying to say. If one thinks of this as > a reference to 10.18 then the ffffffff contradicts the RFC. Hence the > mind shifts back and forth trying to figure out why this paragraph is > even here. > > If you guys think it is clear after reviewing it, then I'll accept > that. Well, I thought it was clear. However the fact we still have this thread active indicates it may not be. All I can think to add is some text to the second sentence: Section 10.19 in [RFC3720] mentions this in passing but noted here again for making it obvious. An ITT value of 0xffffffff is reserved and MUST NOT be used by the initiator to identify an initiator task. The only instance it may be seen on the wire is in a target-initiated NOP-In PDU (and the initiator response to that PDU if necessary). Is that better? Take care, Bill --Apple-Mail-2--1048901239 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC9ACYDJT2Egh26K0RAnnrAJ94dBbBjRWeOr58If+cMvnpJtcpJQCfc7Fa ag8LRwA3Syrr+uTH80ki0ho= =YhTv -----END PGP SIGNATURE----- --Apple-Mail-2--1048901239-- --===============0590402471== 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 --===============0590402471==-- From ips-bounces@ietf.org Fri Aug 05 20:32:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1CcS-0007hH-Do; Fri, 05 Aug 2005 20:32:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1CcQ-0007fN-He for ips@megatron.ietf.org; Fri, 05 Aug 2005 20:32:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12261 for ; Fri, 5 Aug 2005 20:32:52 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1D9b-0007gP-Jl for ips@ietf.org; Fri, 05 Aug 2005 21:07:12 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc12) with SMTP id <2005080600324301200pd3c9e>; Sat, 6 Aug 2005 00:32:44 +0000 Message-ID: <000701c59a1e$5c871460$03031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <000c01c5995f$73eb4af0$03031eac@ivivity.com> <711d160cd12ec246f5ced91daaf49bb8@wasabisystems.com> <001401c59a06$b23360c0$03031eac@ivivity.com> <2565d931498543a740f1c8d4f34d00b5@wasabisystems.com> Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Date: Fri, 5 Aug 2005 20:32:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Maybe you can explain why 10.19 (and 10.18) needs clarification. To me they are clear on the use of the ITT. Eddy ----- Original Message ----- From: "William Studenmund" To: "Eddy Quicksall" Cc: Sent: Friday, August 05, 2005 8:13 PM Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] On Aug 5, 2005, at 2:43 PM, Eddy Quicksall wrote: > Actually I know what the paragraph is trying to say but I think it is > not worded clearly. Also, paragraphs 10.18 and 10.19 are very clear on > this subject so I also wonder why it has to be explained again. > Explaining again in unclear terms can imply unwanted understanding. > > "An ITT value of ... NOT be used by the initiator" ... paragraph 10.19 > is talking about Nop-In's and the initiator does not send NOP-In's. > Hence one wonders what this is trying to say. If one thinks of this as > a reference to 10.18 then the ffffffff contradicts the RFC. Hence the > mind shifts back and forth trying to figure out why this paragraph is > even here. > > If you guys think it is clear after reviewing it, then I'll accept > that. Well, I thought it was clear. However the fact we still have this thread active indicates it may not be. All I can think to add is some text to the second sentence: Section 10.19 in [RFC3720] mentions this in passing but noted here again for making it obvious. An ITT value of 0xffffffff is reserved and MUST NOT be used by the initiator to identify an initiator task. The only instance it may be seen on the wire is in a target-initiated NOP-In PDU (and the initiator response to that PDU if necessary). Is that better? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Aug 05 20:44:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1CnT-0002Nx-4e; Fri, 05 Aug 2005 20:44:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1CnS-0002Np-0O for ips@megatron.ietf.org; Fri, 05 Aug 2005 20:44:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13044 for ; Fri, 5 Aug 2005 20:44:16 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1DKd-00081e-8X for ips@ietf.org; Fri, 05 Aug 2005 21:18:36 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 209CA87084; Fri, 5 Aug 2005 20:44:15 -0400 (EDT) In-Reply-To: <000701c59a1e$5c871460$03031eac@ivivity.com> References: <000c01c5995f$73eb4af0$03031eac@ivivity.com> <711d160cd12ec246f5ced91daaf49bb8@wasabisystems.com> <001401c59a06$b23360c0$03031eac@ivivity.com> <2565d931498543a740f1c8d4f34d00b5@wasabisystems.com> <000701c59a1e$5c871460$03031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <91b1b1c96bacfe82870ff567f621b969@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Date: Fri, 5 Aug 2005 17:44:09 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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="===============0237950575==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0237950575== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--1047038915" Content-Transfer-Encoding: 7bit --Apple-Mail-3--1047038915 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 5, 2005, at 5:32 PM, Eddy Quicksall wrote: > Maybe you can explain why 10.19 (and 10.18) needs clarification. To me > they are clear on the use of the ITT. I'm not sure; I don't know what discussions lead to this section. However I would expect they stem from the fact that RFC 3720 (10.18 and 10.19) never explicitly states that ITT 0xffffffff is reserved overall. Yes, it's in the NOP-OUT and NOP-IN section and they won't work if ITT 0xffffffff isn't reserved. But it's a big thing that should have been mentioned, say in chapter 3 where we discussed primary concepts. "Don't use ITT 0xffffffff for an initiator task's ID" is a big thing. :-) Take care, Bill --Apple-Mail-3--1047038915 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC9AfeDJT2Egh26K0RArRgAJwOuy0w1onvUrHkwxStKggr/09FxgCfVR1m 6FTP4VzbbyEpcf6lecS3N2g= =Psxs -----END PGP SIGNATURE----- --Apple-Mail-3--1047038915-- --===============0237950575== 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 --===============0237950575==-- From ips-bounces@ietf.org Fri Aug 05 21:29:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1DV3-0003rc-VB; Fri, 05 Aug 2005 21:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1DV3-0003rX-39 for ips@megatron.ietf.org; Fri, 05 Aug 2005 21:29:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14517 for ; Fri, 5 Aug 2005 21:29:16 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1E2C-0000Sg-Jb for ips@ietf.org; Fri, 05 Aug 2005 22:03:37 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id 69B0650C0 for ; Fri, 5 Aug 2005 18:28:47 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.153]) by rosemail.rose.hp.com (Postfix) with ESMTP id C28498058 for ; Fri, 5 Aug 2005 14:38:39 -0700 (PDT) Message-ID: <42F41246.5000100@rose.hp.com> Date: Fri, 05 Aug 2005 18:28:38 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] References: <000c01c5995f$73eb4af0$03031eac@ivivity.com> <711d160cd12ec246f5ced91daaf49bb8@wasabisystems.com> <001401c59a06$b23360c0$03031eac@ivivity.com> <2565d931498543a740f1c8d4f34d00b5@wasabisystems.com> <000701c59a1e$5c871460$03031eac@ivivity.com> <91b1b1c96bacfe82870ff567f621b969@wasabisystems.com> In-Reply-To: <91b1b1c96bacfe82870ff567f621b969@wasabisystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >But it's a big thing that should have been > mentioned, say in chapter 3 where we discussed primary concepts. Thanks. That's basically the feedback I received, which I thought was a reasonable request. I will wordsmth the text a bit to make it clearer. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com William Studenmund wrote: > On Aug 5, 2005, at 5:32 PM, Eddy Quicksall wrote: > >> Maybe you can explain why 10.19 (and 10.18) needs clarification. To me >> they are clear on the use of the ITT. > > > I'm not sure; I don't know what discussions lead to this section. > > However I would expect they stem from the fact that RFC 3720 (10.18 and > 10.19) never explicitly states that ITT 0xffffffff is reserved overall. > Yes, it's in the NOP-OUT and NOP-IN section and they won't work if ITT > 0xffffffff isn't reserved. But it's a big thing that should have been > mentioned, say in chapter 3 where we discussed primary concepts. "Don't > use ITT 0xffffffff for an initiator task's ID" is a big thing. :-) > > Take care, > > Bill > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Aug 05 21:47:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1DmO-0007fx-Kj; Fri, 05 Aug 2005 21:47:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1DmI-0007fm-UT for ips@megatron.ietf.org; Fri, 05 Aug 2005 21:47:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15283 for ; Fri, 5 Aug 2005 21:47:08 -0400 (EDT) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1EJU-0000sk-Hk for ips@ietf.org; Fri, 05 Aug 2005 22:21:29 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc14) with SMTP id <2005080601465901400d63die>; Sat, 6 Aug 2005 01:47:00 +0000 Message-ID: <000b01c59a28$bc986340$03031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" References: <000c01c5995f$73eb4af0$03031eac@ivivity.com> <711d160cd12ec246f5ced91daaf49bb8@wasabisystems.com> <001401c59a06$b23360c0$03031eac@ivivity.com> <2565d931498543a740f1c8d4f34d00b5@wasabisystems.com> <000701c59a1e$5c871460$03031eac@ivivity.com> <91b1b1c96bacfe82870ff567f621b969@wasabisystems.com> Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Date: Fri, 5 Aug 2005 21:46:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Ahh, silly me. All this time I thought the paragraph was referring to 10.19 only. How about this then? --- old wording --- > Section 10.19 in [RFC3720] mentions this in passing but noted > here again for making it obvious. An ITT value of 0xffffffff is > reserved and MUST NOT be used by the initiator. The only > instance it may be seen on the wire is in a target-initiated > NOP-In PDU (and the initiator response to that PDU if > necessary). --- new wording --- Except where expressly allowed in sections 10.18 and 10.19, an ITT value of 0xffffffff is reserved and MUST NOT be used by the initiator. Eddy ----- Original Message ----- From: "William Studenmund" To: "Eddy Quicksall" Cc: Sent: Friday, August 05, 2005 8:44 PM Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] On Aug 5, 2005, at 5:32 PM, Eddy Quicksall wrote: > Maybe you can explain why 10.19 (and 10.18) needs clarification. To me > they are clear on the use of the ITT. I'm not sure; I don't know what discussions lead to this section. However I would expect they stem from the fact that RFC 3720 (10.18 and 10.19) never explicitly states that ITT 0xffffffff is reserved overall. Yes, it's in the NOP-OUT and NOP-IN section and they won't work if ITT 0xffffffff isn't reserved. But it's a big thing that should have been mentioned, say in chapter 3 where we discussed primary concepts. "Don't use ITT 0xffffffff for an initiator task's ID" is a big thing. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Aug 06 17:58:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Wh0-0000kO-PE; Sat, 06 Aug 2005 17:58:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1Wgz-0000kJ-Fh for ips@megatron.ietf.org; Sat, 06 Aug 2005 17:58:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14084 for ; Sat, 6 Aug 2005 17:58:54 -0400 (EDT) Message-Id: <200508062158.RAA14084@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1XEK-0000vc-Tc for ips@ietf.org; Sat, 06 Aug 2005 18:33:27 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E1Wgp-000BEa-Kv; Sat, 06 Aug 2005 21:58:47 +0000 To: elizabeth.rodriguez@dothill.com Subject: Re: [Ips] Resignation as chair Date: Sat, 06 Aug 2005 14:58:47 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ips@ietf.org, black_david@emc.com, jon.peterson@neustar.biz X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Elizabeth, This should have been answered a bit quicker, but IETF was busy. I'm sorry you didn't get to Paris for the group to give you a big goodbye hum or some such, but anyway here is a group Thank You. You did a wonderful job in the co-chairship. Thank you for your insighful and hard work, and best of luck with your new activities. Allison _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 08 15:23:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DE2-0004He-Ag; Mon, 08 Aug 2005 15:23:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DDy-0004HZ-G4 for ips@megatron.ietf.org; Mon, 08 Aug 2005 15:23:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12076 for ; Mon, 8 Aug 2005 15:23:48 -0400 (EDT) Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Dlh-0001D0-B7 for ips@ietf.org; Mon, 08 Aug 2005 15:58:43 -0400 Received: from [192.168.7.164] (helo=winminx) by hammer with esmtp (Exim 4.12) id 1E2DAq-0003gE-00; Mon, 08 Aug 2005 20:20:36 +0100 From: "Ken Sandars" To: "'William Studenmund'" , "'Mallikarjun C.'" Subject: RE: [Ips] Re: ISID and Discovery Re:draft-ietf-ips-iscsi-impl-guide-00.txt Date: Mon, 8 Aug 2005 20:22:53 +0100 Message-ID: <006e01c59c4e$a79f8a40$a407a8c0@elipsan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <014d1d1e0e2844a34009de9ed227ca14@wasabisystems.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: 'IPS' X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Gidday all,=20 Sending the TPGT during the discovery login is not going to help the multiple concurrent login situation as the information is too little too late. The reality is that at start-up the initiator IS shooting in the = dark. The only information the initiator might know is the TCP addressing characteristics of the portal(s) to attempt discovery on. It might not = even know if those portals are on the same network entity. If it attempts multiple concurrent discovery logins to all its discovery portals, then it will be in for a rude shock if it encounters a = four-portal network entity using option A! Option B seems better, but say a network entity is configured such that = two portals have the same TPGT and another two have a different TPGT for the spooky 'no-name' target. The first-time concurrent caller is going to = see session reinstatement between the paired portals. I suggest that session reinstatement on unnamed discovery sessions = should be limited to the session on the same portal on which the new connection is being made. In effect, operating like Mallikarjun's option B, but with = each portal in the network entity being assigned to its own portal group in = the "no-name" target node.=20 What are we really trying to achieve by identifying session = reinstatement conditions? Is it just to free up resources at the target network = entity? Given the extremely restricted characteristics of discovery sessions, resource-limited targets are not going to allow discovery sessions to = hang around for long if the initiator doesn't get on with issuing its = SendTargets TEXT pdu and logging out. I'm sure that more than one iSCSI target out = there drops inactive discovery sessions after a certain timeout. Thoughts? Ken Sandars Adaptec, UK > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of William Studenmund > Sent: 04 August 2005 18:51 > To: Mallikarjun C. > Cc: IPS > Subject: Re: [Ips] Re: ISID and Discovery=20 > Re:draft-ietf-ips-iscsi-impl-guide-00.txt >=20 >=20 >=20 > On Aug 3, 2005, at 5:58 PM, Mallikarjun C. wrote: >=20 > > Bill, > > > > > Why though do we have to mandate one or the other? > > > > That is a good question. I thought this was found to be an=20 > > interoperability issue in the past, as evidenced by multiple email=20 > > threads on this topic. And that's why Bob Russell brought this to=20 > > this forum again to document and be done with it. >=20 > I guess my hope was to come up with one behavior/description which=20 > includes both cases. So we have one understanding, one rule, and=20 > different targets could choose different behaviors within this one=20 > rule. >=20 > > Option A, BTW, was the earlier list "conclusion" (I'd stay=20 > away from=20 > > "consensus" for David hasn't called it) as far as I can tell from=20 > > previous email threads. >=20 > I'll be honest. I was part of that "conclusion" and I overlooked the=20 > TPGT aspect of it. :-) >=20 > > As you suggest, we can say: > > a) some targets do no-name discovery session reinstatements=20 > and some=20 > > don't, on matching InitiatorName-ISID; > > b) some targets return TPGT on no-name discovery sessions and some=20 > > don't. > > > > But I thought that was the problem we're trying to address with the=20 > > guide. >=20 > I'm sorry, my original comment was aimed more at the thought that we=20 > had to make a tradeoff with one idea vs the other. I think we=20 > can find=20 > a common ground that will encompass all behaviors. >=20 > My thought is to refine what you say above. On a no-name discovery=20 > session, if a target does not return a TPGT, then the TPGT should be=20 > taken as "" or NULL (as you suggested). Then all targets do session=20 > reinstatement on no-name discovery sessions against other=20 > sessions with=20 > matching InitiatorName-ISID-NULL_TargetName-TPGT. So all portals that=20 > don't return a TPGT will reinstate with each other. All portals that=20 > return TPGT 0 will reinstate with each other, and so on. In=20 > essence we=20 > add "" or NULL to the TPGT space for discovery sessions, and the ISID=20 > rule applies. >=20 > Thus an initiator can figure out what the target is doing and=20 > it should=20 > not be surprised about what is happening. >=20 > I think letting/requiring targets to send a TPGT when they=20 > have a TPGT=20 > in mind (not "" or NULL) is an important change. Without it, the=20 > initiator would be shooting blind and could have little clue=20 > as to what=20 > the target is doing. I think that's bad. So bad that if we don't=20 > permit/require sending a TPGT when the target is acting like=20 > it is not=20 > "" or NULL, then I think we should go with option A. Otherwise I feel=20 > we would have a shooting-in-the-dark situation which feels very messy=20 > to me. >=20 > Take care, >=20 > Bill >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 08 21:01:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2IUk-0002jW-K6; Mon, 08 Aug 2005 21:01:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2IUi-0002jR-C5 for ips@megatron.ietf.org; Mon, 08 Aug 2005 21:01:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09234 for ; Mon, 8 Aug 2005 21:01:26 -0400 (EDT) From: pat_thaler@agilent.com Received: from msgbas9x.lvld.agilent.com ([192.25.144.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2J2V-0005CA-Fk for ips@ietf.org; Mon, 08 Aug 2005 21:36:24 -0400 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas9x.lvld.agilent.com (Postfix) with ESMTP id B2CD51AF for ; Mon, 8 Aug 2005 19:01:09 -0600 (MDT) Received: from wlvdvs01.lvld.agilent.com (wlvdvs01.lvld.agilent.com [148.5.6.4]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 932A7510 for ; Mon, 8 Aug 2005 19:01:09 -0600 (MDT) Received: from wcosbh01.cos.agilent.com ([130.29.152.125]) by wlvdvs01.lvld.agilent.com with InterScan Messaging Security Suite; Mon, 08 Aug 2005 19:01:09 -0600 Received: from wcosmb05.cos.agilent.com ([130.29.152.72]) by wcosbh01.cos.agilent.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 19:01:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Date: Mon, 8 Aug 2005 19:01:08 -0600 Message-ID: <9418406DEC3B8A4BBDB1B87291D851AF01AD52AA@wcosmb05.cos.agilent.com> Thread-Topic: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Thread-index: AcWaJoTcS/TEF52fT06qNQSvq1QQawCOs4Pw To: , X-OriginalArrivalTime: 09 Aug 2005 01:01:09.0037 (UTC) FILETIME=[D3EE1DD0:01C59C7D] X-Spam-Score: 0.3 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I think it is all fine and non-contradictory if one understands "MUST = NOT be used by the initiator" to mean "the initiator MUST NOT create a = task with the ITT" 0xffffffff or "the initiator MUST NOT assign the ITT = 0xffffffff to any task". If one interprets "use" more broadly, e.g. MUST = NOT ever send a PDU with that ITT, then it isn't true for the NOP-IN = response. So perhaps some version of the other words could be used = instead of MUST NOT be used. Regards, Pat -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of = Mallikarjun C. Sent: Friday, 05 August, 2005 6:29 PM To: ips@ietf.org Subject: Re: [Ips] section 5.1 ITT = [draft-ietf-ips-iscsi-impl-guide-00.txt] >But it's a big thing that should have been > mentioned, say in chapter 3 where we discussed primary concepts. Thanks. That's basically the feedback I received, which I thought was a = reasonable request. I will wordsmth the text a bit to make it clearer. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com William Studenmund wrote: > On Aug 5, 2005, at 5:32 PM, Eddy Quicksall wrote: >=20 >> Maybe you can explain why 10.19 (and 10.18) needs clarification. To = me=20 >> they are clear on the use of the ITT. >=20 >=20 > I'm not sure; I don't know what discussions lead to this section. >=20 > However I would expect they stem from the fact that RFC 3720 (10.18 = and=20 > 10.19) never explicitly states that ITT 0xffffffff is reserved = overall.=20 > Yes, it's in the NOP-OUT and NOP-IN section and they won't work if ITT = > 0xffffffff isn't reserved. But it's a big thing that should have been=20 > mentioned, say in chapter 3 where we discussed primary concepts. = "Don't=20 > use ITT 0xffffffff for an initiator task's ID" is a big thing. :-) >=20 > Take care, >=20 > Bill >=20 >=20 > = ------------------------------------------------------------------------ >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 09 09:36:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UHj-00007h-1N; Tue, 09 Aug 2005 09:36:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UHf-00007Z-N5 for ips@megatron.ietf.org; Tue, 09 Aug 2005 09:36:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06692 for ; Tue, 9 Aug 2005 09:36:45 -0400 (EDT) Received: from sccrmhc14.comcast.net ([63.240.76.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Upa-0007tK-Gb for ips@ietf.org; Tue, 09 Aug 2005 10:11:50 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc14) with SMTP id <2005080913363701400d4e72e>; Tue, 9 Aug 2005 13:36:38 +0000 Message-ID: <000701c59ce7$5fe4b650$03031eac@ivivity.com> From: "Eddy Quicksall" To: , , References: <9418406DEC3B8A4BBDB1B87291D851AF01AD52AA@wcosmb05.cos.agilent.com> Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Date: Tue, 9 Aug 2005 09:36:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The main problem with the paragraph is the reference to 10.19. Eddy ----- Original Message ----- From: To: ; Sent: Monday, August 08, 2005 9:01 PM Subject: RE: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] I think it is all fine and non-contradictory if one understands "MUST NOT be used by the initiator" to mean "the initiator MUST NOT create a task with the ITT" 0xffffffff or "the initiator MUST NOT assign the ITT 0xffffffff to any task". If one interprets "use" more broadly, e.g. MUST NOT ever send a PDU with that ITT, then it isn't true for the NOP-IN response. So perhaps some version of the other words could be used instead of MUST NOT be used. Regards, Pat -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Mallikarjun C. Sent: Friday, 05 August, 2005 6:29 PM To: ips@ietf.org Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] >But it's a big thing that should have been > mentioned, say in chapter 3 where we discussed primary concepts. Thanks. That's basically the feedback I received, which I thought was a reasonable request. I will wordsmth the text a bit to make it clearer. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com William Studenmund wrote: > On Aug 5, 2005, at 5:32 PM, Eddy Quicksall wrote: > >> Maybe you can explain why 10.19 (and 10.18) needs clarification. To me >> they are clear on the use of the ITT. > > > I'm not sure; I don't know what discussions lead to this section. > > However I would expect they stem from the fact that RFC 3720 (10.18 and > 10.19) never explicitly states that ITT 0xffffffff is reserved overall. > Yes, it's in the NOP-OUT and NOP-IN section and they won't work if ITT > 0xffffffff isn't reserved. But it's a big thing that should have been > mentioned, say in chapter 3 where we discussed primary concepts. "Don't > use ITT 0xffffffff for an initiator task's ID" is a big thing. :-) > > Take care, > > Bill > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 09 11:20:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VuT-000598-Hs; Tue, 09 Aug 2005 11:20:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2VuR-00058m-Do for ips@megatron.ietf.org; Tue, 09 Aug 2005 11:20:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15205 for ; Tue, 9 Aug 2005 11:20:52 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2WSM-000330-NJ for ips@ietf.org; Tue, 09 Aug 2005 11:55:59 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc12) with SMTP id <2005080915203601400qkctae>; Tue, 9 Aug 2005 15:20:36 +0000 Message-ID: <000501c59cf5$e2ba54f0$03031eac@ivivity.com> From: "Eddy Quicksall" To: , , References: <9418406DEC3B8A4BBDB1B87291D851AF01AD52AA@wcosmb05.cos.agilent.com> <000701c59ce7$5fe4b650$03031eac@ivivity.com> Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Date: Tue, 9 Aug 2005 11:20:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org If it wasn't clear in what I said below, what I mean is the reference to 10.19 as it stands makes one not familiar with the issue the impression that the paragraph is referring to 10.19. My suggestion is that the paragraph be more specific that the issue is the use of a ITT of 0xffffffff and simply reference 10.18 and 10.19 as the one case where the ITT can be 0xffffffff. It would seem that a simple way of saying that is something like: Except where specified in paragraphs 10.18 and 10.19 an ITT of 0xffffffff is reserved and MUST NOT be used by the initiator. Eddy ----- Original Message ----- From: "Eddy Quicksall" To: ; ; Sent: Tuesday, August 09, 2005 9:36 AM Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] > The main problem with the paragraph is the reference to 10.19. > > Eddy > > ----- Original Message ----- > From: > To: ; > Sent: Monday, August 08, 2005 9:01 PM > Subject: RE: [Ips] section 5.1 ITT > [draft-ietf-ips-iscsi-impl-guide-00.txt] > > > I think it is all fine and non-contradictory if one understands "MUST NOT > be used by the initiator" to mean "the initiator MUST NOT create a task > with the ITT" 0xffffffff or "the initiator MUST NOT assign the ITT > 0xffffffff to any task". If one interprets "use" more broadly, e.g. MUST > NOT ever send a PDU with that ITT, then it isn't true for the NOP-IN > response. So perhaps some version of the other words could be used instead > of MUST NOT be used. > > Regards, > Pat > > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of > Mallikarjun C. > Sent: Friday, 05 August, 2005 6:29 PM > To: ips@ietf.org > Subject: Re: [Ips] section 5.1 ITT > [draft-ietf-ips-iscsi-impl-guide-00.txt] > > >But it's a big thing that should have been > > mentioned, say in chapter 3 where we discussed primary concepts. > > Thanks. That's basically the feedback I received, which I thought was a > reasonable request. I will wordsmth the text a bit to make it clearer. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > William Studenmund wrote: >> On Aug 5, 2005, at 5:32 PM, Eddy Quicksall wrote: >> >>> Maybe you can explain why 10.19 (and 10.18) needs clarification. To me >>> they are clear on the use of the ITT. >> >> >> I'm not sure; I don't know what discussions lead to this section. >> >> However I would expect they stem from the fact that RFC 3720 (10.18 and >> 10.19) never explicitly states that ITT 0xffffffff is reserved overall. >> Yes, it's in the NOP-OUT and NOP-IN section and they won't work if ITT >> 0xffffffff isn't reserved. But it's a big thing that should have been >> mentioned, say in chapter 3 where we discussed primary concepts. "Don't >> use ITT 0xffffffff for an initiator task's ID" is a big thing. :-) >> >> Take care, >> >> Bill >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 09 17:26:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2bbk-0002vr-NI; Tue, 09 Aug 2005 17:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2bbj-0002vk-8y for ips@megatron.ietf.org; Tue, 09 Aug 2005 17:25:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15684 for ; Tue, 9 Aug 2005 17:25:54 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2c9e-0007r6-Rz for ips@ietf.org; Tue, 09 Aug 2005 18:01:04 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id 8505780AD for ; Tue, 9 Aug 2005 14:24:47 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.112.41.54]) by rosemail.rose.hp.com (Postfix) with ESMTP id 5C1E9827E for ; Tue, 9 Aug 2005 10:34:23 -0700 (PDT) Message-ID: <42F91F1F.6040708@rose.hp.com> Date: Tue, 09 Aug 2005 14:24:47 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS Subject: Re: [Ips] New thought for draft-ietf-ips-iscsi-impl-guide-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Bill, Sorry, I was traveling part of last week, and all of this week. You raise an interesting question, and I think clarifying this in the Implementer's guide could be useful. Is it reasonable to require that whenever one DNS name maps to multiple IP addresses (v4 or v6), targets must return the specific IP address(es) the TPG can be reached on (not the DNS name), except when the TPG can be reached via all IP addresses (v4 & v6) that the DNS name resolves to? Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com William Studenmund wrote: > One thing I've remembered I wanted to note is that initiators should > prepare themselves for DNS names showing up multiple times in > SendTargets discovery. > > The reason for this is that a TargetAddress value does not indicate if a > DNS address is IPv4 or IPv6. It is possible for a DNS name to map to > both an A and AAAA record. > > If the target's configuration explicitly indicates IPv4 vs IPv6, it is > possible to have different portals on the v4 and v6 addresses for a DNS > name. It is also possible for the different portals to report the same > DNS name and also be in different portal groups. In this case, the TPGT > reported for each would differ. > > Take care, > > Bill > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 09 20:44:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ehT-0005li-0B; Tue, 09 Aug 2005 20:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ehO-0005lc-Sj for ips@megatron.ietf.org; Tue, 09 Aug 2005 20:44:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26698 for ; Tue, 9 Aug 2005 20:44:00 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2fFN-00046Z-En for ips@ietf.org; Tue, 09 Aug 2005 21:19:11 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id B141087075; Tue, 9 Aug 2005 20:43:48 -0400 (EDT) In-Reply-To: <42F91F1F.6040708@rose.hp.com> References: <42F91F1F.6040708@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <5d79522c8c4e5ee8f1517d4d623b9e89@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] New thought for draft-ietf-ips-iscsi-impl-guide-00.txt Date: Tue, 9 Aug 2005 17:43:39 -0700 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0552079175==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0552079175== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6--701468274" Content-Transfer-Encoding: 7bit --Apple-Mail-6--701468274 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: quoted-printable On Aug 9, 2005, at 2:24 PM, Mallikarjun C. wrote: > Bill, > > Sorry, I was traveling part of last week, and all of this week. > > You raise an interesting question, and I think clarifying this in the=20= > Implementer's guide could be useful. > > Is it reasonable to require that whenever one DNS name maps to=20 > multiple IP addresses (v4 or v6), targets must return the specific IP=20= > address(es) the TPG can be reached on (not the DNS name), except when=20= > the TPG can be reached via all IP addresses (v4 & v6) that the DNS=20 > name resolves to? As a target implementer, I'd rather not do that. However what you=20 describe makes a lot of sense and would probably be a clean thing to=20 do. I'd rather not do it, but it could be easier than the pain=20 initiators would see. Oh, I'd restrict the requirement to portals (TargetAddress entries) on=20= the same TCP port; if a TCP port number is served by only one IP=20 address family (v4 or v6), no restriction seems needed. Changing the=20 port number makes differing TargetAddresses look different, so the=20 initiators should be able to handle that situation. Also, I'd phrase it=20= that the TPG is the same for all IP addresses. Rather than reaching a=20 TPG, you're reaching a portal that is in a TPG. As a nit, I think I'd phrase this as requiring that portals that are=20 configured to use a common DNS name MUST all use the same TPGT for any=20= given target. If a common DNS name is configured for portals that=20 belong to different TPGs, the target MUST report the resolved IP=20 addresses rather than the DNS names. Hmmm... That's still wordy and mushy. What I'm trying to get to is that the target only needs to look at=20 portals that are configured to use the same DNS name, it doesn't have=20 to look up a DNS name and then try and find out what portals all map to=20= the returned addresses. Having to do DNS lookups on all hostnames and=20 then having to sift through all the returned records would be a mess. So the algorithm I have in mind is that the target scans all the (text)=20= host names. For each host name, if all the portals are members of the=20 same TPG, then the DNS name can be returned. Otherwise the numeric=20 addresses have to be returned. Note that since the TPGs are strictly=20 defined per-node, this calculation could get interesting. :-) Next question, is it ok for the target to return multiple identical=20 =10TargetAddress entries? This would only happen if it's ok to use a DNS=20= name and we have both a v4 and v6 portal. I think it'd be easier for=20 targets to permit this, and it could also serve as an indication to=20 initiators that there really are multiple portals present. Any input from initiator folks? How much would/will this issue confuse=20= your discovery systems? Take care, Bill --Apple-Mail-6--701468274 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC+U3ADJT2Egh26K0RAvF4AJ9Ch8ke02cbBVSZ1FaUOoEs6E8orgCfbB/u bZeUkdwJc40Hz7yqb3WQA84= =fnBL -----END PGP SIGNATURE----- --Apple-Mail-6--701468274-- --===============0552079175== 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 --===============0552079175==-- From ips-bounces@ietf.org Tue Aug 09 22:53:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2gij-0004Dt-IN; Tue, 09 Aug 2005 22:53:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2gih-0004Dk-Ic for ips@megatron.ietf.org; Tue, 09 Aug 2005 22:53:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01091 for ; Tue, 9 Aug 2005 22:53:28 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2hGi-0006tk-DP for ips@ietf.org; Tue, 09 Aug 2005 23:28:41 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j7A2rRHu000407 for ; Tue, 9 Aug 2005 22:53:28 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Aug 2005 22:53:27 -0400 Message-ID: To: ips@ietf.org Date: Tue, 9 Aug 2005 22:53:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.8.9.37 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Ips] IPS DRAFT Paris minutes X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org These are the draft minutes - please send corrections to me. The only decision made in the meeting was on the generalization of iSER to allow use with IB - I will post a separate message on that. Thanks, --David The IP Storage (ips) WG meets 1815-1945 on Tuesday, August 2, 2005 at the IETF meetings in Paris, France. AGENDA ------ Administrivia, agenda bashing, draft status review, etc.: 15 min David L. Black, EMC (co-chair) Blue sheets Note Well WG chair change - Elizabeth Rodriguez has resigned as co-chair. David Black will continue as the sole chair. Milestones (charter milestones need revision) Draft status - iSER and DA are through WG Last Call. Publication will be requested by end of August. MIB Status (I-D tracker is not up to date): - MIBs requiring expert re-review: SCSI, iFCP, iSCSI - Expert review comments received and waiting for new version: FCIP, iSCSI Authorization - New version of MIB recently submitted, needs expert review: iSNS iFCP draft is in RFC Editor's queue, among others. iFCP appears to be waiting on authors to respond to RFC Editor question on references. iSCSI Implementer's Guide (draft-ietf-ips-iscsi-impl-guide-00.txt): 15 min David L. Black, EMC (co-chair) for Mallikarjun Chadalapaka, HP (editor) FYI and opportunity for comments. The draft will remain open well into 2006, and the mailing list is the primary forum for working on it. iSER over InfiniBand: up to 1 hour John Hufferd, Brocade draft-hufferd-iser-ib-00.txt Proposal for text edits to iSER to permit use on other transports, including InfiniBand. Also will help enable iSER to be defined over SCTP. See John's slides. Important meeting notes: SHOULD implement IPsec-equivalent security for non-IP transports appears to be the right approach (no objection in room - WG chair is ok with this). iSER discovery on IB will rely upon (and require presence of) IP over IB. Sense of room: Want to proceed towards applying these changes (after careful review and WG rough consensus) to the approved iSER draft so that there is one draft that is broadly applicable rather than the current iSER draft plus a draft that modifies that draft to broaden it. iSCSI Discovery Data Extensions: Conceptual Discussion John Hufferd, Brocade Extending iSCSI discovery to support other transports. Meeting discussion: Not sure until all the details are worked out, starting with backwards compatibility and protocol gateways of varying transparency. Overall approach is worthy of further investigation. ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 09 23:02:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2gr2-0007mn-P2; Tue, 09 Aug 2005 23:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2gr0-0007iN-RA for ips@megatron.ietf.org; Tue, 09 Aug 2005 23:02:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01461 for ; Tue, 9 Aug 2005 23:02:04 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2hP2-00075i-K0 for ips@ietf.org; Tue, 09 Aug 2005 23:37:16 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j7A322kQ004080 for ; Tue, 9 Aug 2005 23:02:03 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Aug 2005 23:02:02 -0400 Message-ID: To: ips@ietf.org Date: Tue, 9 Aug 2005 23:01:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.8.9.37 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ips] iSER over IB - Consensus call X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The IPS WG Paris meeting discussed: iSER over InfiniBand (draft-hufferd-iser-ib-00.txt) Proposal for text edits to iSER to permit use on other transports, including InfiniBand. Also will help enable iSER to be defined over SCTP. This draft is (or at least is intended to be) entirely editorial - it does not (or at least is not intended to) make any technical changes to the iSER draft that has passed WG Last Call. The draft Paris minutes record the following: Sense of room: Want to proceed towards applying these changes (after careful review and WG rough consensus) to the approved iSER draft so that there is one draft that is broadly applicable rather than the current iSER draft plus a draft that modifies that draft to broaden it. Anyone who objects to this sense of the room in Paris should post to the list with reasons for the objection, otherwise the sense of the room to proceed in this direction will become the rough consensus of the IPS WG. If the WG does proceed in this direction, the next step will be a WG Last Call on draft-hufferd-iser-ib-00.txt, with all changes/comments/etc. to be posted to the list, even editorial ones. After conclusion of that WG Last Call, the resulting edits can be applied to produce a new version of the iSER draft. We'll try to get this done by the end of August, but it may take a bit longer. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 10 07:56:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pCK-0006FU-Qd; Wed, 10 Aug 2005 07:56:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pCJ-0006FP-Az for ips@megatron.ietf.org; Wed, 10 Aug 2005 07:56:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21938 for ; Wed, 10 Aug 2005 07:56:38 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2pkN-0003g4-So for ips@ietf.org; Wed, 10 Aug 2005 08:31:54 -0400 Received: by zproxy.gmail.com with SMTP id i1so76992nzh for ; Wed, 10 Aug 2005 04:56:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=CAVvLcDDtAuH3PJiIm9GBkRH0dQvpb5QcBgyDpi7rBqzBZ/6Z5poqyFBoRtgt039M0YRZxlMIpBqiMBK9haJE2JnEX7ecd/3Nm8lEFPFtFxZSQZppDrU0ujIFJHPVY6pg0ELebP6kEs7W+qmer7KSDTjSCUJe51kU47iF6jdAyE= Received: by 10.36.96.11 with SMTP id t11mr600880nzb; Wed, 10 Aug 2005 04:56:28 -0700 (PDT) Received: by 10.37.22.70 with HTTP; Wed, 10 Aug 2005 04:56:28 -0700 (PDT) Message-ID: <8320074d0508100456561df3bd@mail.gmail.com> Date: Wed, 10 Aug 2005 17:26:28 +0530 From: Rohan Sen To: ISCSI Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: [Ips] Connection Reinstatement as per RFC3720 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org For connection reinstatement on the client side, section 5.3.4 and 5.3.5 it states that, "The Login Request performs the logout function of the old connection if an explicit logout was not performed earlier." This does not speak anything about the state of the older connection, i.e,. whether it torn down or not. But again in the finite state machine diagram in section 7.1.3, it seems that the connection closure in imperative (identified by transiiton T15/T16) for transiting to CLEANUP_WAIT state which I understood is a MUST for any attempt for connection reinstatement (which is very obvious also). So, once the connection is no longer there, we need to open a new connection (over TCP) with the Target and send Login Request PDU. The only difference in this Login Request can be the value of the 'TSIH' field which MUST be set to zero for connection reinstatement. Will it be wrong if I assume that it is this field only which determines whether the Login Request is for a new connection or connection reinstatement ? --=20 thanks, Rohan Sen _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 10 14:34:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vPJ-0004Em-SN; Wed, 10 Aug 2005 14:34:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vPF-0004EV-Uy for ips@megatron.ietf.org; Wed, 10 Aug 2005 14:34:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15779 for ; Wed, 10 Aug 2005 14:34:23 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2vxO-00071m-43 for ips@ietf.org; Wed, 10 Aug 2005 15:09:43 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id DD252870A1; Wed, 10 Aug 2005 14:34:10 -0400 (EDT) In-Reply-To: <000501c59cf5$e2ba54f0$03031eac@ivivity.com> References: <9418406DEC3B8A4BBDB1B87291D851AF01AD52AA@wcosmb05.cos.agilent.com> <000701c59ce7$5fe4b650$03031eac@ivivity.com> <000501c59cf5$e2ba54f0$03031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <984912dc24cb2c6489d8c59036de2e4d@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] section 5.1 ITT [draft-ietf-ips-iscsi-impl-guide-00.txt] Date: Wed, 10 Aug 2005 11:34:03 -0700 To: "Eddy Quicksall" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ips@ietf.org, pat_thaler@agilent.com, cbm@rose.hp.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0142114651==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0142114651== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6--637244375" Content-Transfer-Encoding: 7bit --Apple-Mail-6--637244375 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 9, 2005, at 8:20 AM, Eddy Quicksall wrote: > If it wasn't clear in what I said below, what I mean is the reference > to 10.19 as it stands makes one not familiar with the issue the > impression that the paragraph is referring to 10.19. > > My suggestion is that the paragraph be more specific that the issue is > the use of a ITT of 0xffffffff and simply reference 10.18 and 10.19 as > the one case where the ITT can be 0xffffffff. > > It would seem that a simple way of saying that is something like: > > Except where specified in paragraphs 10.18 and 10.19 an ITT of > 0xffffffff is reserved and MUST NOT be used by the initiator. Since we're all word-smithing, how about: An ITT of 0xFFFFFFFF is reserved and MUST NOT be used by the initiator except as specified in paragraphs 10.18 and 10.19. The difference is that 0xFFFFFFFF is always reserved, and 10.18 and 10.19 explain how it is used. :-) As an aside, what text do we have indicating that TTT 0xFFFFFFFF is reserved and can only be used for unsolicited data? I'd expect that we could use a similar construct here. Take care, Bill --Apple-Mail-6--637244375 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC+kihDJT2Egh26K0RAivdAJ0QJz7PhpYafKSazcGI0qlzQa9ypwCeP9Qb GAe+bx0n43GBBapJ+ktlzlo= =dTsB -----END PGP SIGNATURE----- --Apple-Mail-6--637244375-- --===============0142114651== 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 --===============0142114651==-- From ips-bounces@ietf.org Wed Aug 10 14:37:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vSf-0004yl-CX; Wed, 10 Aug 2005 14:37:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vSd-0004yZ-3n for ips@megatron.ietf.org; Wed, 10 Aug 2005 14:37:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16238 for ; Wed, 10 Aug 2005 14:37:53 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2w0n-0007DT-5A for ips@ietf.org; Wed, 10 Aug 2005 15:13:13 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 4B40B8707A; Wed, 10 Aug 2005 14:37:53 -0400 (EDT) In-Reply-To: <5d79522c8c4e5ee8f1517d4d623b9e89@wasabisystems.com> References: <42F91F1F.6040708@rose.hp.com> <5d79522c8c4e5ee8f1517d4d623b9e89@wasabisystems.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <3ce14509877907612679d815f0bf247f@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] New thought for draft-ietf-ips-iscsi-impl-guide-00.txt Date: Wed, 10 Aug 2005 11:37:46 -0700 To: William Studenmund X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: IPS , "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1724021822==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1724021822== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7--637021517" Content-Transfer-Encoding: 7bit --Apple-Mail-7--637021517 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 9, 2005, at 5:43 PM, William Studenmund wrote: > On Aug 9, 2005, at 2:24 PM, Mallikarjun C. wrote: > >> Bill, >> >> Sorry, I was traveling part of last week, and all of this week. >> >> You raise an interesting question, and I think clarifying this in the >> Implementer's guide could be useful. >> >> Is it reasonable to require that whenever one DNS name maps to >> multiple IP addresses (v4 or v6), targets must return the specific IP >> address(es) the TPG can be reached on (not the DNS name), except when >> the TPG can be reached via all IP addresses (v4 & v6) that the DNS >> name resolves to? > > As a target implementer, I'd rather not do that. However what you > describe makes a lot of sense and would probably be a clean thing to > do. I'd rather not do it, but it could be easier than the pain > initiators would see. > > Oh, I'd restrict the requirement to portals (TargetAddress entries) on > the same TCP port; if a TCP port number is served by only one IP > address family (v4 or v6), no restriction seems needed. Changing the > port number makes differing TargetAddresses look different, so the > initiators should be able to handle that situation. Also, I'd phrase > it that the TPG is the same for all IP addresses. Rather than reaching > a TPG, you're reaching a portal that is in a TPG. I'm sorry I wasn't able to make the IETF in Paris. But I had an idea after reading David's minutes. If we are going to extend SendTargets discovery to cover other transports, like IB, then we could perhaps also extend the discovery to be explicit about which IP transport (v4 or v6) to use. Thus the ambiguity will be gone. Take care, Bill --Apple-Mail-7--637021517 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC+kl/DJT2Egh26K0RAobHAJ9dXCaHSV3h2QLCXeDfd7mRG6ewCwCdHHfm f4jFMmru2TLItkj2HqaFbqo= =L17b -----END PGP SIGNATURE----- --Apple-Mail-7--637021517-- --===============1724021822== 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 --===============1724021822==-- From ips-bounces@ietf.org Wed Aug 10 14:55:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vjn-0003vx-8m; Wed, 10 Aug 2005 14:55:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vjl-0003vl-J4 for ips@megatron.ietf.org; Wed, 10 Aug 2005 14:55:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18980 for ; Wed, 10 Aug 2005 14:55:36 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2wHu-0008No-N9 for ips@ietf.org; Wed, 10 Aug 2005 15:30:56 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id D96788707A; Wed, 10 Aug 2005 14:55:34 -0400 (EDT) In-Reply-To: <8320074d0508100456561df3bd@mail.gmail.com> References: <8320074d0508100456561df3bd@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] Connection Reinstatement as per RFC3720 Date: Wed, 10 Aug 2005 11:55:23 -0700 To: Rohan Sen X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ISCSI X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0353264892==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0353264892== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10--635964924" Content-Transfer-Encoding: 7bit --Apple-Mail-10--635964924 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 10, 2005, at 4:56 AM, Rohan Sen wrote: > For connection reinstatement on the client side, section 5.3.4 and > 5.3.5 it states that, > "The Login Request performs > the logout function of the old connection if an explicit logout was > not performed earlier." > This does not speak anything about the state of the older connection, > i.e,. whether it torn down or not. > > But again in the finite state machine diagram in section 7.1.3, it > seems that the connection closure in imperative (identified by > transiiton T15/T16) for transiting to CLEANUP_WAIT state which I > understood is a MUST for any attempt for connection reinstatement > (which is very obvious also). > > So, once the connection is no longer there, we need to open a new > connection (over TCP) with the Target and send Login Request PDU. The > only difference in this Login Request can be the value of the 'TSIH' > field which MUST be set to zero for connection reinstatement. No. A TSIH of zero indicates SESSION reinstatement, not connection reinstatement. > Will it be wrong if I assume that it is this field only which > determines whether the Login Request is for a new connection or > connection reinstatement ? Yes. See the table in section 5.3.1 which indicates what TSIH/ISID and CID values indicate what. Connection reinstatement happens when the ISID, TSIH, and CID of the new connection match an existing connection. Take care, Bill --Apple-Mail-10--635964924 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC+k2jDJT2Egh26K0RAsv/AJsHeBXCzjPiZCVuWzeUBWjKOotPpQCeOiY1 O/3CiehbgdeAGmHRtyeSeX8= =PG3S -----END PGP SIGNATURE----- --Apple-Mail-10--635964924-- --===============0353264892== 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 --===============0353264892==-- From ips-bounces@ietf.org Thu Aug 11 22:12:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3P28-0002Ar-Ge; Thu, 11 Aug 2005 22:12:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3P25-0002Ae-SE for ips@megatron.ietf.org; Thu, 11 Aug 2005 22:12:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12564 for ; Thu, 11 Aug 2005 22:12:27 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3PaT-0000ZE-KM for ips@ietf.org; Thu, 11 Aug 2005 22:48:04 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id B4333870BD for ; Thu, 11 Aug 2005 22:12:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v622) Message-Id: To: ISCSI From: William Studenmund Date: Thu, 11 Aug 2005 19:11:56 -0700 X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Ips] Question about invalid PDUs and SCSI sense data 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="===============1138947166==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1138947166== Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-9--523371323" --Apple-Mail-9--523371323 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I'm looking through some potential invalid PDU cases, and wondering about what would be appropriate sense data. For all of these cases, let the invalid iSCSI PDUs relate to an instantiated SCSI task. As I understand it, the invalid PDU should be responded to with a Reject PDU (0x3F) and a Reason code of 0x09. I however want to also kill off the related SCSI task, and as per Note 2 in RFC 3720 section 10.17.1, I have to report SCSI sense info. I however don't know what appropriate sense data are for all cases. There are some cases mentioned in the spec in section 10.4.7, and they are clear. However my imagination has come up with more, and I'm not so sure about them. I _think_ I can find existing ASC/ASCQ values, but wanted input. Case 1: Data-Out PDU received with no corresponding valid TTT. Note: I am implicitly assuming the target examines ITT before TTT; if it examined TTT before ITT, then the Data-Out PDU wouldn't match a task and no task would be impacted. Would Sense Key Aborted Command (0x0b), ASC/Q 0x4b/0x00 Data Phase Error be appropriate? Case 2: Data-Out PDU in a write command with invalid parameters. For a specific example, the Data-Out is for a TTT other than 0xffffffff, the ITT matches the ITT associated with that TTT, and its LUN field differs from that of the command. As I understand the paragraph at the top of page 141, "the LUN field MUST hold a valid value and be consistent with whatever was specified with the command." Another example is Buffer Offset out of bounds for the TTT. I haven't found a good ASC/Q. 0x49/0x00 Invalid Message Error maybe? Yes, it's normally a SPI thing, but it indicates an error with transport level messages, which is what's happening here. Oh, hmmm... I think the Buffer Offset issue specifically could use 0x4b/0x05 Data Offset Error. But Buffer Offset isn't the only parameter error that can happen. Thoughts? Take care, Bill --Apple-Mail-9--523371323 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC/AVyDJT2Egh26K0RAsTGAKCXVj3fne2C5Vl9i+uS+W1XcxfGhgCeLB1S +8viT+04mz+LwfODAJ3BoJs= =NG20 -----END PGP SIGNATURE----- --Apple-Mail-9--523371323-- --===============1138947166== 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 --===============1138947166==-- From ips-bounces@ietf.org Fri Aug 12 09:02:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZAi-00025p-EZ; Fri, 12 Aug 2005 09:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZAg-000256-Dm for ips@megatron.ietf.org; Fri, 12 Aug 2005 09:02:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20557 for ; Fri, 12 Aug 2005 09:02:00 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ZjB-0008W5-MD for ips@ietf.org; Fri, 12 Aug 2005 09:37:43 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j7CD1jZZ025373 for ; Fri, 12 Aug 2005 09:01:45 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j7CD1jNd025366; Fri, 12 Aug 2005 09:01:45 -0400 Received: from PKONING.equallogic.com ([172.16.1.186]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 09:01:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17148.40378.31000.983106@gargle.gargle.HOWL> Date: Fri, 12 Aug 2005 09:01:46 -0400 From: Paul Koning To: wrstuden@wasabisystems.com Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data References: X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 12 Aug 2005 13:01:45.0523 (UTC) FILETIME=[FE1F9030:01C59F3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "William" == William Studenmund writes: William> I'm looking through some potential invalid PDU cases, and William> wondering about what would be appropriate sense data. William> For all of these cases, let the invalid iSCSI PDUs relate to William> an instantiated SCSI task. ... How would you know that? The way I look at invalid PDUs is that the sender is confused, so you can't trust any of the bits in the PDU. In particular, if the sender doesn't know how to speak the protocol correctly, what assurance do you have that the TTT is right? paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Aug 12 09:41:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZnE-0003Kg-Ng; Fri, 12 Aug 2005 09:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZnC-0003Kb-RX for ips@megatron.ietf.org; Fri, 12 Aug 2005 09:41:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22458 for ; Fri, 12 Aug 2005 09:41:48 -0400 (EDT) From: dcuddihy@attotech.com Received: from sw.attotech.com ([12.32.232.56] helo=noteserv1.attotech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3aLj-0001EX-Fh for ips@ietf.org; Fri, 12 Aug 2005 10:17:31 -0400 To: ips@ietf.org Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data MIME-Version: 1.0 Message-ID: Date: Fri, 12 Aug 2005 09:41:45 -0400 Content-Type: multipart/mixed; boundary="=_mixed 004B3BFA8525705B_=" X-Spam-Score: 0.4 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --=_mixed 004B3BFA8525705B_= Content-Type: multipart/alternative; boundary="=_alternative 004B3BFA8525705B_=" --=_alternative 004B3BFA8525705B_= Content-Type: text/plain; charset="US-ASCII" Bill, >> if it examined TTT before ITT, then the Data-Out PDU wouldn't match a task >> and no task would be impacted. I agree. The target should probably send a reject PDU. >> Would Sense Key Aborted Command (0x0b), ASC/Q 0x4b/0x00 Data Phase Error be appropriate? That makes sense to me. I've seen targets return 4b 00 in the case of a data direction error and data size mismatches on FC and parallel SCSI. (By the way - anyone know what 4b 01 Invalid Transfer Port Target Tag is for?) BUT . . . Since this is may be a recoverable transport error, not a SCSI error, why abort the SCSI task at the target? Seems to me that the target should send a reject PDU and wait for the initiator to try to fix the problem. The target doesn't know if this error is recoverable or not, and the initiator can always use task manglement to abort the command itself. regards, david David J Cuddihy, Principal Engineer ATTO Technology, Inc. http://www.attotech.com/bridge.html William Studenmund Sent by: ips-bounces@ietf.org 08/11/2005 10:11 PM To ISCSI cc Subject [Ips] Question about invalid PDUs and SCSI sense data I'm looking through some potential invalid PDU cases, and wondering about what would be appropriate sense data. For all of these cases, let the invalid iSCSI PDUs relate to an instantiated SCSI task. As I understand it, the invalid PDU should be responded to with a Reject PDU (0x3F) and a Reason code of 0x09. I however want to also kill off the related SCSI task, and as per Note 2 in RFC 3720 section 10.17.1, I have to report SCSI sense info. I however don't know what appropriate sense data are for all cases. There are some cases mentioned in the spec in section 10.4.7, and they are clear. However my imagination has come up with more, and I'm not so sure about them. I _think_ I can find existing ASC/ASCQ values, but wanted input. Case 1: Data-Out PDU received with no corresponding valid TTT. Note: I am implicitly assuming the target examines ITT before TTT; if it examined TTT before ITT, then the Data-Out PDU wouldn't match a task and no task would be impacted. Would Sense Key Aborted Command (0x0b), ASC/Q 0x4b/0x00 Data Phase Error be appropriate? Case 2: Data-Out PDU in a write command with invalid parameters. For a specific example, the Data-Out is for a TTT other than 0xffffffff, the ITT matches the ITT associated with that TTT, and its LUN field differs from that of the command. As I understand the paragraph at the top of page 141, "the LUN field MUST hold a valid value and be consistent with whatever was specified with the command." Another example is Buffer Offset out of bounds for the TTT. I haven't found a good ASC/Q. 0x49/0x00 Invalid Message Error maybe? Yes, it's normally a SPI thing, but it indicates an error with transport level messages, which is what's happening here. Oh, hmmm... I think the Buffer Offset issue specifically could use 0x4b/0x05 Data Offset Error. But Buffer Offset isn't the only parameter error that can happen. Thoughts? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 004B3BFA8525705B_= Content-Type: text/html; charset="US-ASCII"
Bill,

>> if it examined TTT before ITT, then the Data-Out PDU wouldn't match a task
>> and no task would be impacted.

I agree.  The target should probably send a reject PDU.

>> Would Sense Key Aborted Command (0x0b), ASC/Q 0x4b/0x00 Data Phase Error be appropriate?  

That makes sense to me.  I've seen targets return 4b 00 in the case of a data direction error and data size mismatches on FC and parallel SCSI.  (By the way - anyone know what 4b 01 Invalid Transfer Port Target Tag is for?)

BUT . . . Since this is may be a recoverable transport error, not a SCSI error, why abort the SCSI task at the target?  Seems to me that the target should send a reject PDU and wait for the initiator to try to fix the problem.  The target doesn't know if this error is recoverable or not, and the initiator can always use task manglement to abort the command itself.

regards,

david


David J Cuddihy, Principal Engineer
ATTO Technology, Inc.
http://www.attotech.com/bridge.html



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

08/11/2005 10:11 PM

To
ISCSI <ips@ietf.org>
cc
Subject
[Ips] Question about invalid PDUs and SCSI sense data





I'm looking through some potential invalid PDU cases, and wondering
about what would be appropriate sense data.

For all of these cases, let the invalid iSCSI PDUs relate to an
instantiated SCSI task. As I understand it, the invalid PDU should be
responded to with a Reject PDU (0x3F) and a Reason code of 0x09. I
however want to also kill off the related SCSI task, and as per Note 2
in RFC 3720 section 10.17.1, I have to report SCSI sense info.

I however don't know what appropriate sense data are for all cases.
There are some cases mentioned in the spec in section 10.4.7, and they
are clear. However my imagination has come up with more, and I'm not so
sure about them. I _think_ I can find existing ASC/ASCQ values, but
wanted input.

Case 1: Data-Out PDU received with no corresponding valid TTT. Note: I
am implicitly assuming the target examines ITT before TTT; if it
examined TTT before ITT, then the Data-Out PDU wouldn't match a task
and no task would be impacted. Would Sense Key Aborted Command (0x0b),
ASC/Q 0x4b/0x00 Data Phase Error be appropriate?

Case 2: Data-Out PDU in a write command with invalid parameters.

For a specific example, the Data-Out is for a TTT other than
0xffffffff, the ITT matches the ITT associated with that TTT, and its
LUN field differs from that of the command. As I understand the
paragraph at the top of page 141, "the LUN field MUST hold a valid
value and be consistent with whatever was specified with the command."
Another example is Buffer Offset out of bounds for the TTT.

I haven't found a good ASC/Q. 0x49/0x00 Invalid Message Error maybe?
Yes, it's normally a SPI thing, but it indicates an error with
transport level messages, which is what's happening here.

Oh, hmmm... I think the Buffer Offset issue specifically could use
0x4b/0x05 Data Offset Error. But Buffer Offset isn't the only parameter
error that can happen.

Thoughts?

Take care,

Bill
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 004B3BFA8525705B_=-- --=_mixed 004B3BFA8525705B_= Content-Type: application/octet-stream; name="PGP.sig" Content-Disposition: attachment; filename="PGP.sig" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAoRGFy d2luKQ0KDQppRDhEQlFGQy9BVnlESlQyRWdoMjZLMFJBc1RHQUtDWFZqM2ZuZTJDNVZsOWkrdVMr VzFYY3hmR2hnQ2VMQjFTDQorOHZpVCswNG16K0x3Zk9EQUozQm9Kcz0NCj1ORzIwDQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --=_mixed 004B3BFA8525705B_= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_mixed 004B3BFA8525705B_=-- From ips-bounces@ietf.org Fri Aug 12 13:28:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dKY-000233-Hc; Fri, 12 Aug 2005 13:28:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dKW-00022Y-TH for ips@megatron.ietf.org; Fri, 12 Aug 2005 13:28:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07044 for ; Fri, 12 Aug 2005 13:28:24 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3dt4-0008G3-3m for ips@ietf.org; Fri, 12 Aug 2005 14:04:11 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id D2FB38709F; Fri, 12 Aug 2005 13:28:13 -0400 (EDT) In-Reply-To: <17148.40378.31000.983106@gargle.gargle.HOWL> References: <17148.40378.31000.983106@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <7844a59a1ebd330370596d39ba226012@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data Date: Fri, 12 Aug 2005 10:28:04 -0700 To: Paul Koning X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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="===============1890662606==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1890662606== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--468403726" Content-Transfer-Encoding: 7bit --Apple-Mail-1--468403726 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 12, 2005, at 6:01 AM, Paul Koning wrote: >>>>>> "William" == William Studenmund >>>>>> writes: > > William> I'm looking through some potential invalid PDU cases, and > William> wondering about what would be appropriate sense data. > > William> For all of these cases, let the invalid iSCSI PDUs relate to > William> an instantiated SCSI task. ... > > How would you know that? Good question. The target will have to look at different fields in the PDU to figure out where to route the PDU, and at some point enough of the fields will match to indicate a PDU belongs with a task. All the values (ITT, TTT, LUN) are supposed to match, so any time when they don't is an error case. Exactly where that happens is up to the target. But I think it's perfectly reasonable for the target to get upset once whatever list of match criteria have been met and something else doesn't match. > The way I look at invalid PDUs is that the sender is confused, so you > can't trust any of the bits in the PDU. In particular, if the sender > doesn't know how to speak the protocol correctly, what assurance do > you have that the TTT is right? Well, if we think the sender's that confused, why continue trying to talk to it? :-) So why not kill a task with this errant party. :-) The Reject PDU explicitly states that if a SCSI task is terminated as a result of the Reject, SCSI sense data MUST be sent. While I agree it doesn't state that you MUST terminate a SCSI task, it certainly indicates that the idea of an iSCSI Reject leading to a SCSI task dying is accepted. We already have examples in RFC 3720 where we report SCSI Sense data in response to iSCSI protocol confusion. Unsolicited data when it's not supposed to be there, too much unsolicited data, or a bad SNACK all have recommended Sense Data. All three of those cases are where we think we can (logically) tie a PDU to a task even though there was confusion. So I think I agree and disagree with you. I think you're right that we need to make sure we think a PDU relates to a task before escalating an iSCSI Reject into a SCSI event, but I disagree in that I think there is a class of iSCSI Rejects which should also turn into SCSI events. In light of your question, though, I think I'll require the initiator get (ITT, TTT) right first. :-) Take care, Bill --Apple-Mail-1--468403726 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC/NwpDJT2Egh26K0RAmjUAJ0Z1xEdgJjTGBRYs/k6pMO5+qctZACgg7Cx N37kBPgoetiH/oN19l6PYE4= =CG7I -----END PGP SIGNATURE----- --Apple-Mail-1--468403726-- --===============1890662606== 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 --===============1890662606==-- From ips-bounces@ietf.org Fri Aug 12 13:49:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dez-0007ly-Ar; Fri, 12 Aug 2005 13:49:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dex-0007lt-TU for ips@megatron.ietf.org; Fri, 12 Aug 2005 13:49:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07890 for ; Fri, 12 Aug 2005 13:49:34 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3eDW-0000L3-Sz for ips@ietf.org; Fri, 12 Aug 2005 14:25:19 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 7B2D38709F; Fri, 12 Aug 2005 13:49:34 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data Date: Fri, 12 Aug 2005 10:49:27 -0700 To: dcuddihy@attotech.com X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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="===============1546530706==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1546530706== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--467120447" Content-Transfer-Encoding: 7bit --Apple-Mail-2--467120447 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Aug 12, 2005, at 6:41 AM, dcuddihy@attotech.com wrote: > Bill, > > >> if it examined TTT before ITT, then the Data-Out PDU wouldn't match=20= > a task > >> and no task would be impacted. > > I agree. =A0The target should probably send a reject PDU. > > >> Would Sense Key Aborted Command (0x0b), ASC/Q 0x4b/0x00 Data Phase=20= > Error be appropriate? =A0 > > That makes sense to me. =A0I've seen targets return 4b 00 in the case = of=20 > a data direction error and data size mismatches on FC and parallel=20 > SCSI. =A0(By the way - anyone know what 4b 01 Invalid Transfer Port=20 > Target Tag is for?) Google says it's a SAS thing. > BUT . . . Since this is may be a recoverable transport error, not a=20 > SCSI error, why abort the SCSI task at the target? =A0Seems to me that=20= > the target should send a reject PDU and wait for the initiator to try=20= > to fix the problem. =A0The target doesn't know if this error is=20 > recoverable or not, and the initiator can always use task manglement=20= > to abort the command itself. I actually talked about a few error cases in the original message. Some=20= of them may be recoverable, while others may not. I'm now tempted=20 (after this and Paul's note) to just handle ITT/TTT mismatch as a=20 reject and leave the task alone. But I think we should kill the task if=20= something like Buffer Offset is wrong. Among other things, I don't want=20= to try and place the data in that case. Something's wrong, so let's=20 stop and try again. Take care, Bill --Apple-Mail-2--467120447 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFC/OEsDJT2Egh26K0RAinmAJ0eyRbIk0HtHk93r8HoPs86tHkAEACfREOc FqtZi5DmJeSsSq/gPSbU6+s= =aB4c -----END PGP SIGNATURE----- --Apple-Mail-2--467120447-- --===============1546530706== 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 --===============1546530706==-- From ips-bounces@ietf.org Mon Aug 15 14:20:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jZT-0008E3-I6; Mon, 15 Aug 2005 14:20:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jZQ-0008Dv-Vf for ips@megatron.ietf.org; Mon, 15 Aug 2005 14:20:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17752 for ; Mon, 15 Aug 2005 14:20:23 -0400 (EDT) Received: from volter-fw.ser.netvision.net.il ([212.143.107.30] helo=taurus.voltaire.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4k8Y-0005xV-TU for ips@ietf.org; Mon, 15 Aug 2005 14:56:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Aug 2005 21:20:03 +0300 Message-ID: Thread-Topic: Login Phase in iSER over IB Thread-Index: AcWhxfTiVdWY1cL+Qy+nYWrnEUFv+Q== From: "Alex Nezhinsky" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Subject: [Ips] Login Phase in iSER over IB 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="===============1876545905==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1876545905== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A1C5.F234F8F1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A1C5.F234F8F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to propose some changes for the "iSER over IB" draft (http://www.ietf.org/internet-drafts/draft-hufferd-iser-ib-00.txt). The changes being proposed address a group of statements regarding possible mechanisms of message exchange during the iSER Login Phase in protocols such as IB.=20 The following statement is an example (section 3.1.6): "For LLPs that have message delivery capability such as [IB], the iSCSI Layer may use that messaging capability immediately after connection establishment before enabling iSER-assisted mode." Because IB as such does not provide streaming capability equivalent to the plain (not RDMA-enabled) TCP mode in iWARP, a substitute for it should be found elsewhere. One option is to use the messaging capabilities provided by the transport layer itself. This is a valid option because the Login phase exchange is carried out in half-duplex mode. It can be understood from the previous statement that using two separate connections for the iSCSI Login and iSER Full-Feature phases is also allowed. For example, the Login phase is carried out using an IPoIB connection, while the iSER part is carried out using a separate IB RC connection.=20 In order to clarify that only using a single transport connection is mandated, the following changes are proposed: 1) In 3.1.6 the third paragraph is to be replaced with: "And in that same section (4.1) the next to last * paragraph is hereby replaced with the following:=20 * For a transport layer that operates in stream mode such as TCP, the RDMA-Capable Protocol implementation supports the enabling of the RDMA mode after Connection establishment and the exchange of Login parameters in stream mode. For a transport layer that provides message delivery capability, such as [IB], the RDMA-Capable Protocol implementation supports the use of this messaging capability by the iSCSI Layer directly for the Login phase after connection establishment before enabling iSER-assisted mode." 2) In 3.1.6.1 the first paragraph is to be repaced with: "For a transport layer that provides message delivery capability, such as [IB], the iSCSI Layer MUST interact with the transport layer directly to use the messaging capability for exchanging the iSCSI Login Request and Login Response PDUs. The method for establishing the actual connection is protocol specific and outside the scope of this specification. The same connection MUST be used for both the iSCSI Login phase and the subsequent iSER-supported Full-Feature phase. Alexander Nezhinsky Software Engineer Infiniband Storage Solutions www.voltaire.com =20 9 Ha-Menofim, Herzelya 46725 Israel tel: +972- 9- 9717637 fax: +972- 9- 9717660 mobile: +972-50-7504376 ------_=_NextPart_001_01C5A1C5.F234F8F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to propose some = changes for the=20 "iSER over IB" draft (http://www.ietf.org/internet-drafts/draft-hufferd-iser-ib-00.txt). The=20 changes being proposed address a group of statements regarding possible=20 mechanisms of message exchange during the iSER Login Phase in protocols = such as=20 IB.

The following statement is an example (section = 3.1.6):=20 "For LLPs that have message delivery capability such as [IB], the iSCSI = Layer=20 may use that messaging capability immediately after = connection=20 establishment before enabling iSER-assisted mode."

Because IB as such does not provide streaming capability equivalent to the plain (not = RDMA-enabled) TCP=20 mode in iWARP, a substitute for it=20 should be found elsewhere. One = option is to=20 use the messaging capabilities provided by the transport layer itself. = This is a=20 valid option because the Login phase exchange is carried out in = half-duplex=20 mode. It can be understood from the previous statement that using two separate connections = for the=20 iSCSI Login and iSER Full-Feature phases is also allowed. For example, the Login = phase is=20 carried out using an IPoIB connection, while the iSER part is carried = out=20 using a separate IB RC = connection.

In order to clarify that only using a single transport = connection=20 is mandated, the following changes are proposed:

1) In 3.1.6 the third paragraph is to be = replaced=20 with:

"And in that same section (4.1) = the next to=20 last * paragraph is hereby replaced with the following: =

    * For a transport = layer that=20 operates in stream mode such as TCP, the RDMA-Capable Protocol = implementation=20 supports the enabling of the RDMA mode after Connection establishment = and the=20 exchange of Login parameters in stream mode. For a transport layer that = provides=20 message delivery capability, = such as [IB],=20 the RDMA-Capable Protocol implementation supports the use of this = messaging=20 capability by the iSCSI Layer directly for the Login phase after = connection=20 establishment before enabling iSER-assisted = mode."

2) In 3.1.6.1 the first paragraph is to = be repaced=20 with:

"For a transport layer that = provides message=20 delivery capability, such as = [IB], the=20 iSCSI Layer MUST interact with the transport layer directly to use the = messaging=20 capability for exchanging the iSCSI Login Request and Login Response = PDUs. The=20 method for establishing the actual connection is protocol specific and = outside=20 the scope of this specification. The same connection MUST be used for = both the=20 iSCSI Login phase and the subsequent iSER-supported Full-Feature=20 phase.

Alexander = Nezhinsky

Software = Engineer
Infiniband = Storage=20 Solutions
www.voltaire.com
9 Ha-Menofim, = Herzelya=20 46725 Israel
tel: +972- 9-=20 9717637
fax: +972- 9-=20 9717660
mobile:=20 +972-50-7504376
------_=_NextPart_001_01C5A1C5.F234F8F1-- --===============1876545905== 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 --===============1876545905==-- From ips-bounces@ietf.org Mon Aug 15 14:44:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jwS-0002aw-Ez; Mon, 15 Aug 2005 14:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jwP-0002am-Pw for ips@megatron.ietf.org; Mon, 15 Aug 2005 14:44:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18851 for ; Mon, 15 Aug 2005 14:44:07 -0400 (EDT) Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4kVZ-0006Ty-Kb for ips@ietf.org; Mon, 15 Aug 2005 15:20:30 -0400 Received: from hq-ex-5.corp.brocade.com (hq-ex-5 [192.168.38.35]) by blasphemy.brocade.com (Postfix) with ESMTP id BD16414259; Mon, 15 Aug 2005 11:43:51 -0700 (PDT) Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by hq-ex-5.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Aug 2005 11:43:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Login Phase in iSER over IB Date: Mon, 15 Aug 2005 11:43:51 -0700 Message-ID: Thread-Topic: [Ips] Login Phase in iSER over IB Thread-Index: AcWhxfTiVdWY1cL+Qy+nYWrnEUFv+QAA0L6w From: "John Hufferd" To: "Alex Nezhinsky" , X-OriginalArrivalTime: 15 Aug 2005 18:43:51.0496 (UTC) FILETIME=[47CBBC80:01C5A1C9] X-Spam-Score: 0.3 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 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="===============1181347095==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1181347095== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A1C9.47A1CF97" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A1C9.47A1CF97 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am OK, with these proposed changes. =20 . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 =20 _____ =20 From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Alex Nezhinsky Sent: Monday, August 15, 2005 11:20 AM To: ips@ietf.org Subject: [Ips] Login Phase in iSER over IB =20 I would like to propose some changes for the "iSER over IB" draft (http://www.ietf.org/internet-drafts/draft-hufferd-iser-ib-00.txt). The changes being proposed address a group of statements regarding possible mechanisms of message exchange during the iSER Login Phase in protocols such as IB.=20 The following statement is an example (section 3.1.6): "For LLPs that have message delivery capability such as [IB], the iSCSI Layer may use that messaging capability immediately after connection establishment before enabling iSER-assisted mode." Because IB as such does not provide streaming capability equivalent to the plain (not RDMA-enabled) TCP mode in iWARP, a substitute for it should be found elsewhere. One option is to use the messaging capabilities provided by the transport layer itself. This is a valid option because the Login phase exchange is carried out in half-duplex mode. It can be understood from the previous statement that using two separate connections for the iSCSI Login and iSER Full-Feature phases is also allowed. For example, the Login phase is carried out using an IPoIB connection, while the iSER part is carried out using a separate IB RC connection.=20 In order to clarify that only using a single transport connection is mandated, the following changes are proposed: 1) In 3.1.6 the third paragraph is to be replaced with: "And in that same section (4.1) the next to last * paragraph is hereby replaced with the following:=20 * For a transport layer that operates in stream mode such as TCP, the RDMA-Capable Protocol implementation supports the enabling of the RDMA mode after Connection establishment and the exchange of Login parameters in stream mode. For a transport layer that provides message delivery capability, such as [IB], the RDMA-Capable Protocol implementation supports the use of this messaging capability by the iSCSI Layer directly for the Login phase after connection establishment before enabling iSER-assisted mode." 2) In 3.1.6.1 the first paragraph is to be repaced with: "For a transport layer that provides message delivery capability, such as [IB], the iSCSI Layer MUST interact with the transport layer directly to use the messaging capability for exchanging the iSCSI Login Request and Login Response PDUs. The method for establishing the actual connection is protocol specific and outside the scope of this specification. The same connection MUST be used for both the iSCSI Login phase and the subsequent iSER-supported Full-Feature phase. Alexander Nezhinsky Software Engineer Infiniband Storage Solutions www.voltaire.com =20 9 Ha-Menofim, Herzelya 46725 Israel tel: +972- 9- 9717637 fax: +972- 9- 9717660 mobile: +972-50-7504376 ------_=_NextPart_001_01C5A1C9.47A1CF97 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am OK, with these proposed = changes.

 

.

.

.

John L Hufferd

Sr. Executive Director of = Technology

Brocade Communications Systems, = Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; = eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; = Cell: (408) 627-9606

 

From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Alex Nezhinsky
Sent: Monday, August 15, = 2005 11:20 AM
To: ips@ietf.org
Subject: [Ips] Login = Phase in iSER over IB

 

I would like to propose some changes for the "iSER over IB" = draft (http://www.ietf.org/internet-drafts/draft-hufferd-iser-ib-00.txt). The changes being proposed address a group of statements regarding = possible mechanisms of message exchange during the iSER Login Phase in protocols = such as IB.

The following statement is an example (section 3.1.6): "For LLPs that = have message delivery capability such as [IB], the iSCSI Layer = may use that messaging capability immediately after connection establishment = before enabling iSER-assisted mode."

Because IB as such does not provide streaming capability equivalent to the = plain (not RDMA-enabled) TCP mode in iWARP, a substitute for it should be = found elsewhere. One option is to use the messaging capabilities provided = by the transport layer itself. This is a valid option because the Login phase = exchange is carried out in half-duplex mode. It can be understood from the = previous statement that using two separate connections for the iSCSI Login = and iSER Full-Feature phases is also allowed. For example, the Login phase = is carried out using an IPoIB connection, while the iSER part is carried = out using a separate IB RC connection. =

In order to clarify that only using a single transport connection is mandated, the following changes are = proposed:

1) In 3.1.6 the third paragraph is to be replaced = with:

"And in that same section (4.1) the next to last * paragraph = is hereby replaced with the following: =

    * For a transport layer that operates in = stream mode such as TCP, the RDMA-Capable Protocol implementation supports the = enabling of the RDMA mode after Connection establishment and the exchange of Login parameters in stream mode. For a transport layer that provides message = delivery capability, such as [IB], the RDMA-Capable Protocol implementation = supports the use of this messaging capability by the iSCSI Layer directly for the = Login phase after connection establishment before enabling iSER-assisted = mode."

2) In 3.1.6.1 the first paragraph is to be repaced = with:

"For a transport layer that provides message delivery = capability, such as [IB], the iSCSI Layer MUST interact with the transport layer = directly to use the messaging capability for exchanging the iSCSI Login Request = and Login Response PDUs. The method for establishing the actual connection = is protocol specific and outside the scope of this specification. The same connection MUST be used for both the iSCSI Login phase and the = subsequent iSER-supported Full-Feature = phase.

Alexander Nezhinsky

Software Engineer

Infiniband Storage = Solutions

www.voltaire.com

9 Ha-Menofim, Herzelya 46725 Israel

tel: +972- 9- = 9717637

fax: +972- 9- = 9717660

mobile: = +972-50-7504376

------_=_NextPart_001_01C5A1C9.47A1CF97-- --===============1181347095== 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 --===============1181347095==-- From ips-bounces@ietf.org Mon Aug 15 15:52:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4l0y-0001yz-4B; Mon, 15 Aug 2005 15:52:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4l0w-0001yu-71 for ips@megatron.ietf.org; Mon, 15 Aug 2005 15:52:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23377 for ; Mon, 15 Aug 2005 15:52:52 -0400 (EDT) Received: from rwcrmhc13.comcast.net ([216.148.227.118] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4la5-0008EH-B4 for ips@ietf.org; Mon, 15 Aug 2005 16:29:16 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc13) with SMTP id <20050815195238015004q83se>; Mon, 15 Aug 2005 19:52:39 +0000 Message-ID: <001e01c5a1d2$e4276bc0$03031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" , "Paul Koning" References: <17148.40378.31000.983106@gargle.gargle.HOWL> <7844a59a1ebd330370596d39ba226012@wasabisystems.com> Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data Date: Mon, 15 Aug 2005 15:52:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>We already have examples in RFC 3720 where we report SCSI Sense data in response to iSCSI protocol confusion. I've always wondered about these kind of examples. Exactly what is the initiator supposed to do when it finds that the target has reported a protocol error? Do you think the initiator will try a different method. It will probably resend the same PDU, close the connection, crash or do something else stupid. To me the target should send the reject/sense data but should then close the connection and let the author of the initiator code fix his bug. Eddy ----- Original Message ----- From: "William Studenmund" To: "Paul Koning" Cc: Sent: Friday, August 12, 2005 1:28 PM Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 15 16:03:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lBI-0005ih-8K; Mon, 15 Aug 2005 16:03:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lBH-0005iW-3x for ips@megatron.ietf.org; Mon, 15 Aug 2005 16:03:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26267 for ; Mon, 15 Aug 2005 16:03:33 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4lkS-0000rg-F1 for ips@ietf.org; Mon, 15 Aug 2005 16:39:57 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j7FK3IZb032709 for ; Mon, 15 Aug 2005 16:03:18 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j7FK3INd032704; Mon, 15 Aug 2005 16:03:18 -0400 Received: from pkoning.equallogic.com ([172.16.1.163]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 16:03:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17152.62725.554643.467021@gargle.gargle.HOWL> Date: Mon, 15 Aug 2005 16:03:17 -0400 From: Paul Koning To: eddy_quicksall_iVivity_iSCSI@comcast.net Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data References: <17148.40378.31000.983106@gargle.gargle.HOWL> <7844a59a1ebd330370596d39ba226012@wasabisystems.com> <001e01c5a1d2$e4276bc0$03031eac@ivivity.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 15 Aug 2005 20:03:18.0606 (UTC) FILETIME=[6136FEE0:01C5A1D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Eddy" == Eddy Quicksall writes: >>> We already have examples in RFC 3720 where we report SCSI Sense >>> data in Eddy> response to iSCSI protocol confusion. Eddy> I've always wondered about these kind of examples. Exactly what Eddy> is the initiator supposed to do when it finds that the target Eddy> has reported a protocol error? Right. I can't see any sense in spending effort on complicated rules for protocol errors. Just nuke the session and walk away. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 15 16:06:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lDw-0007EL-PS; Mon, 15 Aug 2005 16:06:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lDv-0007E3-R1 for ips@megatron.ietf.org; Mon, 15 Aug 2005 16:06:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27269 for ; Mon, 15 Aug 2005 16:06:17 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4ln5-0001G4-PA for ips@ietf.org; Mon, 15 Aug 2005 16:42:41 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc12) with SMTP id <20050815200604014009s23ge>; Mon, 15 Aug 2005 20:06:04 +0000 Message-ID: <003501c5a1d4$c454aef0$03031eac@ivivity.com> From: "Eddy Quicksall" To: "William Studenmund" , References: Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data Date: Mon, 15 Aug 2005 16:06:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >> BUT . . . Since this is may be a recoverable transport error, not a >> SCSI error, why abort the SCSI task at the target? On TCP/IP, how can there be a recoverable transport error? For example, if an error is going to occur and it happens to be on the DataSegmentLength, then you will not be able to receive anymore PDU's (without markers and digests). If the connection is such that the IP CRC is not reliable then iSCSI digests are in order. If you aren't using digests and you are saying you want to cover the cases where an error can slip by the IP CRC, the chance of an error hitting the ITT/TTT (or some other detectable PDU field) but nothing else (like undetectable PDU fields or data) is extremely small. What I'm trying to say here is that catching a protocol error may be useful but catching a transport error is fruitless. This is not to say that you don't have a good point as to exactly what sense data to use given the various situations. Eddy ----- Original Message ----- From: "William Studenmund" To: Cc: Sent: Friday, August 12, 2005 1:49 PM Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 15 16:20:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lRy-0001sR-AP; Mon, 15 Aug 2005 16:20:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4lRw-0001qN-Vm for ips@megatron.ietf.org; Mon, 15 Aug 2005 16:20:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02477 for ; Mon, 15 Aug 2005 16:20:46 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4m18-0003Co-24 for ips@ietf.org; Mon, 15 Aug 2005 16:57:11 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc12) with SMTP id <20050815202036014009sti3e>; Mon, 15 Aug 2005 20:20:36 +0000 Message-ID: <004601c5a1d6$cbd27d90$03031eac@ivivity.com> From: "Eddy Quicksall" To: , "William Studenmund" References: <17148.40378.31000.983106@gargle.gargle.HOWL><7844a59a1ebd330370596d39ba226012@wasabisystems.com><001e01c5a1d2$e4276bc0$03031eac@ivivity.com> <17152.62725.554643.467021@gargle.gargle.HOWL> Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data Date: Mon, 15 Aug 2005 16:20:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org BTW, I didn't mean to duck your original issue and that is "what sense data should be given for particular errors". I think there are people on the reflector that are familiar with that issue so I will look forward to those responses. Thanks, Eddy ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Monday, August 15, 2005 4:03 PM Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data >>>>>> "Eddy" == Eddy Quicksall >>>>>> writes: > > >>> We already have examples in RFC 3720 where we report SCSI Sense > >>> data in > Eddy> response to iSCSI protocol confusion. > > Eddy> I've always wondered about these kind of examples. Exactly what > Eddy> is the initiator supposed to do when it finds that the target > Eddy> has reported a protocol error? > > Right. > > I can't see any sense in spending effort on complicated rules for > protocol errors. Just nuke the session and walk away. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 15 17:29:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mWP-0004wb-24; Mon, 15 Aug 2005 17:29:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mWM-0004wT-Pv for ips@megatron.ietf.org; Mon, 15 Aug 2005 17:29:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05565 for ; Mon, 15 Aug 2005 17:29:24 -0400 (EDT) Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4n5Y-0004mk-6k for ips@ietf.org; Mon, 15 Aug 2005 18:05:49 -0400 Received: from hq-ex-3.corp.brocade.com (hq-ex-3 [192.168.38.76]) by blasphemy.brocade.com (Postfix) with ESMTP id 2F8A41427C; Mon, 15 Aug 2005 14:29:11 -0700 (PDT) Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by hq-ex-3.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Aug 2005 14:28:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data Date: Mon, 15 Aug 2005 14:28:47 -0700 Message-ID: Thread-Topic: [Ips] Question about invalid PDUs and SCSI sense data Thread-Index: AcWh1uo3tcb4ngmpRtqximiXZMjDRwACQdYA From: "John Hufferd" To: "Eddy Quicksall" , , "William Studenmund" X-OriginalArrivalTime: 15 Aug 2005 21:28:47.0933 (UTC) FILETIME=[52882ED0:01C5A1E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I expect we should leave it up to the initiator, since they might be probing the target with vendor specific items, which the target can not handle, or early implementations of still un-standardized features. Not that we should pre approve any of these, but we should just leave it as it is, and let the initiator deal with it. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Eddy Quicksall Sent: Monday, August 15, 2005 1:21 PM To: ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data BTW, I didn't mean to duck your original issue and that is "what sense data=20 should be given for particular errors". I think there are people on the=20 reflector that are familiar with that issue so I will look forward to those=20 responses. Thanks, Eddy ----- Original Message -----=20 From: "Paul Koning" To: Cc: Sent: Monday, August 15, 2005 4:03 PM Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data >>>>>> "Eddy" =3D=3D Eddy Quicksall =20 >>>>>> writes: > > >>> We already have examples in RFC 3720 where we report SCSI Sense > >>> data in > Eddy> response to iSCSI protocol confusion. > > Eddy> I've always wondered about these kind of examples. Exactly what > Eddy> is the initiator supposed to do when it finds that the target > Eddy> has reported a protocol error? > > Right. > > I can't see any sense in spending effort on complicated rules for > protocol errors. Just nuke the session and walk away. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 15 21:09:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pwt-0006s1-9E; Mon, 15 Aug 2005 21:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pws-0006rw-0E for ips@megatron.ietf.org; Mon, 15 Aug 2005 21:09:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17600 for ; Mon, 15 Aug 2005 21:09:00 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4qW4-0001Vf-Fr for ips@ietf.org; Mon, 15 Aug 2005 21:45:26 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7G18jI9090906 for ; Mon, 15 Aug 2005 21:08:45 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7G18fos246708 for ; Mon, 15 Aug 2005 21:08:41 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7G18fnj031267 for ; Mon, 15 Aug 2005 21:08:41 -0400 Received: from [9.56.227.90] (d01ml604.pok.ibm.com [9.56.227.90]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7G18f3W031264 for ; Mon, 15 Aug 2005 21:08:41 -0400 Importance: Normal MIME-Version: 1.0 To: ips@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Mon, 15 Aug 2005 18:08:39 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_08072005|August 07, 2005) at 08/15/2005 21:08:41, Serialize complete at 08/15/2005 21:08:41 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ips] Updates to draft-hufferd-iser-ib-00.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The following changes were intended by the internet draft and should be added to section 3 of draft-hufferd-iser-ib: In section 3.1.6 of the iSER draft, last paragraph, replace the sentence "The Final_Login_Response_PDU input qualifier is applicable only for a target, and contains the final Login Response PDU that concludes the iSCSI Login Phase and which must be sent as a byte stream as expected by the iSCSI Layer at the initiator." by "The Final_Login_Response_PDU input qualifier is applicable only for a target, and contains the final Login Response PDU that concludes the iSCSI Login Phase. If the underlying transport is TCP, the final Login Response PDU must be sent as a byte stream as expected by the iSCSI Layer at the initiator." In section 7.3.9 of the iSER draft, first paragraph, replace the sentence "The Login Request PDUs and the Login Response PDUs are exchanged when the connection between the initiator and the target is still in the byte stream mode." by "If the underlying transport is TCP, the Login Request PDUs and the Login Response PDUs are exchanged when the connection between the initiator and the target is still in the byte stream mode." Mike _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 16 03:24:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4vno-0003ph-7y; Tue, 16 Aug 2005 03:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4vnm-0003pW-U0; Tue, 16 Aug 2005 03:24:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25324; Tue, 16 Aug 2005 03:24:01 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4wN4-0000ZJ-QY; Tue, 16 Aug 2005 04:00:31 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j7G7Nmxt138876; Tue, 16 Aug 2005 07:23:48 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7G7NmJ3155972; Tue, 16 Aug 2005 09:23:48 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j7G7NmWG020023; Tue, 16 Aug 2005 09:23:48 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j7G7NmPD020020; Tue, 16 Aug 2005 09:23:48 +0200 In-Reply-To: To: William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M6_06302005 Beta 4NP June 30, 2005 From: Julian Satran Message-ID: Date: Tue, 16 Aug 2005 10:23:47 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 16/08/2005 10:23:48 Content-Type: multipart/mixed; boundary="=_mixed 005D33A84225705E_=" X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: dcuddihy@attotech.com, ips@ietf.org, ips-bounces@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --=_mixed 005D33A84225705E_= Content-Type: multipart/alternative; boundary="=_alternative 005D33AA4225705E_=" --=_alternative 005D33AA4225705E_= Content-Type: text/plain; charset="US-ASCII" According to SPC you could chose response code 70h (immediate) and a sense key of 5h illegal request - provided (as it was said already) that you can recognize the ITT. If you can't and you are a target then either you or the initiator are brain dead and you may start by closing connection/session etc. Julo William Studenmund Sent by: ips-bounces@ietf.org 12-08-05 19:49 To dcuddihy@attotech.com cc ips@ietf.org Subject Re: [Ips] Question about invalid PDUs and SCSI sense data On Aug 12, 2005, at 6:41 AM, dcuddihy@attotech.com wrote: > Bill, > > >> if it examined TTT before ITT, then the Data-Out PDU wouldn't match > a task > >> and no task would be impacted. > > I agree. The target should probably send a reject PDU. > > >> Would Sense Key Aborted Command (0x0b), ASC/Q 0x4b/0x00 Data Phase > Error be appropriate? > > That makes sense to me. I've seen targets return 4b 00 in the case of > a data direction error and data size mismatches on FC and parallel > SCSI. (By the way - anyone know what 4b 01 Invalid Transfer Port > Target Tag is for?) Google says it's a SAS thing. > BUT . . . Since this is may be a recoverable transport error, not a > SCSI error, why abort the SCSI task at the target? Seems to me that > the target should send a reject PDU and wait for the initiator to try > to fix the problem. The target doesn't know if this error is > recoverable or not, and the initiator can always use task manglement > to abort the command itself. I actually talked about a few error cases in the original message. Some of them may be recoverable, while others may not. I'm now tempted (after this and Paul's note) to just handle ITT/TTT mismatch as a reject and leave the task alone. But I think we should kill the task if something like Buffer Offset is wrong. Among other things, I don't want to try and place the data in that case. Something's wrong, so let's stop and try again. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005D33AA4225705E_= Content-Type: text/html; charset="US-ASCII"
According to SPC you could chose response code 70h (immediate) and a sense key of 5h illegal request - provided (as it was said already) that you can recognize the ITT. If you can't and you are a target then either you or the initiator are brain dead and you may start by closing connection/session etc.

Julo


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

12-08-05 19:49

To
dcuddihy@attotech.com
cc
ips@ietf.org
Subject
Re: [Ips] Question about invalid PDUs and SCSI sense data





On Aug 12, 2005, at 6:41 AM, dcuddihy@attotech.com wrote:

> Bill,
>
> >> if it examined TTT before ITT, then the Data-Out PDU wouldn't match
> a task
>  >> and no task would be impacted.
>
> I agree.  The target should probably send a reject PDU.
>
> >> Would Sense Key Aborted Command (0x0b), ASC/Q 0x4b/0x00 Data Phase
> Error be appropriate?  
>
> That makes sense to me.  I've seen targets return 4b 00 in the case of
> a data direction error and data size mismatches on FC and parallel
> SCSI.  (By the way - anyone know what 4b 01 Invalid Transfer Port
> Target Tag is for?)

Google says it's a SAS thing.

> BUT . . . Since this is may be a recoverable transport error, not a
> SCSI error, why abort the SCSI task at the target?  Seems to me that
> the target should send a reject PDU and wait for the initiator to try
> to fix the problem.  The target doesn't know if this error is
> recoverable or not, and the initiator can always use task manglement
> to abort the command itself.

I actually talked about a few error cases in the original message. Some
of them may be recoverable, while others may not. I'm now tempted
(after this and Paul's note) to just handle ITT/TTT mismatch as a
reject and leave the task alone. But I think we should kill the task if
something like Buffer Offset is wrong. Among other things, I don't want
to try and place the data in that case. Something's wrong, so let's
stop and try again.

Take care,

Bill
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 005D33AA4225705E_=-- --=_mixed 005D33A84225705E_= Content-Type: application/octet-stream; name="PGP.sig" Content-Disposition: attachment; filename="PGP.sig" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAoRGFy d2luKQ0KDQppRDhEQlFGQy9PRXNESlQyRWdoMjZLMFJBaW5tQUowZXlSYklrMEh0SGs5M3I4SG9Q czg2dEhrQUVBQ2ZSRU9jDQpGcXRaaTVEbUplU3NTcS9nUFNiVTYrcz0NCj1hQjRjDQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --=_mixed 005D33A84225705E_= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_mixed 005D33A84225705E_=-- From ips-bounces@ietf.org Tue Aug 16 08:19:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50Py-00036z-Rs; Tue, 16 Aug 2005 08:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50Px-00036t-IC for ips@megatron.ietf.org; Tue, 16 Aug 2005 08:19:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06521 for ; Tue, 16 Aug 2005 08:19:43 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E50zH-0007ff-Df for ips@ietf.org; Tue, 16 Aug 2005 08:56:16 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc12) with SMTP id <20050816121934014009m01se>; Tue, 16 Aug 2005 12:19:34 +0000 Message-ID: <000501c5a25c$bf4aabc0$03031eac@ivivity.com> From: "Eddy Quicksall" To: "John Hufferd" , , "William Studenmund" References: Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data Date: Tue, 16 Aug 2005 08:19:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I didn't know we (the RFC) allowed for probing with invalid values. Isn't that part of the reason the RFC has so many MUST's? Take the recent use of 0xFFFFFFFF for the ITT. It is now being made clear that the initiator must not use that except for NOP's. If probing with invalid values is allowed, it should be cleared up in draft-ietf-ips-iscsi-impl-guide-00.txt. Eddy ----- Original Message ----- From: "John Hufferd" To: "Eddy Quicksall" ; ; "William Studenmund" Sent: Monday, August 15, 2005 5:28 PM Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data I expect we should leave it up to the initiator, since they might be probing the target with vendor specific items, which the target can not handle, or early implementations of still un-standardized features. Not that we should pre approve any of these, but we should just leave it as it is, and let the initiator deal with it. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Eddy Quicksall Sent: Monday, August 15, 2005 1:21 PM To: ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data BTW, I didn't mean to duck your original issue and that is "what sense data should be given for particular errors". I think there are people on the reflector that are familiar with that issue so I will look forward to those responses. Thanks, Eddy ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Monday, August 15, 2005 4:03 PM Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data >>>>>> "Eddy" == Eddy Quicksall >>>>>> writes: > > >>> We already have examples in RFC 3720 where we report SCSI Sense > >>> data in > Eddy> response to iSCSI protocol confusion. > > Eddy> I've always wondered about these kind of examples. Exactly what > Eddy> is the initiator supposed to do when it finds that the target > Eddy> has reported a protocol error? > > Right. > > I can't see any sense in spending effort on complicated rules for > protocol errors. Just nuke the session and walk away. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 16 12:58:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54lN-0003VM-U2; Tue, 16 Aug 2005 12:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54lM-0003V8-7u for ips@megatron.ietf.org; Tue, 16 Aug 2005 12:58:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23271 for ; Tue, 16 Aug 2005 12:58:04 -0400 (EDT) Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E55Ki-0006m1-0Z for ips@ietf.org; Tue, 16 Aug 2005 13:34:41 -0400 Received: from hq-ex-7.corp.brocade.com (hq-ex-7 [192.168.38.33]) by blasphemy.brocade.com (Postfix) with ESMTP id 32DCF142FB; Tue, 16 Aug 2005 09:57:46 -0700 (PDT) Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by hq-ex-7.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Aug 2005 09:57:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data Date: Tue, 16 Aug 2005 09:57:34 -0700 Message-ID: Thread-Topic: [Ips] Question about invalid PDUs and SCSI sense data Thread-Index: AcWiXM64spX5Dg4OQ7CokFAgBzrcLAAJiGFQ From: "John Hufferd" To: "Eddy Quicksall" , , "William Studenmund" X-OriginalArrivalTime: 16 Aug 2005 16:57:45.0266 (UTC) FILETIME=[9FA3E120:01C5A283] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org We neither allow nor disallow it. It has no effect on interoperability as long as the spec is followed by the target. This is stuff that developers all do when first developing code that will involve moving from one level to another. It is best that we continue our current direction. It hurts no one, and is useful to many. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]=20 Sent: Tuesday, August 16, 2005 5:19 AM To: John Hufferd; ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data I didn't know we (the RFC) allowed for probing with invalid values. Isn't=20 that part of the reason the RFC has so many MUST's? Take the recent use of=20 0xFFFFFFFF for the ITT. It is now being made clear that the initiator must=20 not use that except for NOP's. If probing with invalid values is allowed, it should be cleared up in=20 draft-ietf-ips-iscsi-impl-guide-00.txt. Eddy ----- Original Message -----=20 From: "John Hufferd" To: "Eddy Quicksall" ;=20 ; "William Studenmund" Sent: Monday, August 15, 2005 5:28 PM Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data I expect we should leave it up to the initiator, since they might be probing the target with vendor specific items, which the target can not handle, or early implementations of still un-standardized features. Not that we should pre approve any of these, but we should just leave it as it is, and let the initiator deal with it. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Eddy Quicksall Sent: Monday, August 15, 2005 1:21 PM To: ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data BTW, I didn't mean to duck your original issue and that is "what sense data should be given for particular errors". I think there are people on the reflector that are familiar with that issue so I will look forward to those responses. Thanks, Eddy ----- Original Message -----=20 From: "Paul Koning" To: Cc: Sent: Monday, August 15, 2005 4:03 PM Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data >>>>>> "Eddy" =3D=3D Eddy Quicksall >>>>>> writes: > > >>> We already have examples in RFC 3720 where we report SCSI Sense > >>> data in > Eddy> response to iSCSI protocol confusion. > > Eddy> I've always wondered about these kind of examples. Exactly what > Eddy> is the initiator supposed to do when it finds that the target > Eddy> has reported a protocol error? > > Right. > > I can't see any sense in spending effort on complicated rules for > protocol errors. Just nuke the session and walk away. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 16 14:36:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56Ib-0003m4-2Q; Tue, 16 Aug 2005 14:36:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56IY-0003j0-FH for ips@megatron.ietf.org; Tue, 16 Aug 2005 14:36:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27660 for ; Tue, 16 Aug 2005 14:36:28 -0400 (EDT) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56rv-0000m3-Nr for ips@ietf.org; Tue, 16 Aug 2005 15:13:05 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (sccrmhc13) with SMTP id <2005081618361901300laepge>; Tue, 16 Aug 2005 18:36:19 +0000 Message-ID: <000301c5a291$64e14650$03031eac@ivivity.com> From: "Eddy Quicksall" To: "John Hufferd" , , "William Studenmund" References: Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data Date: Tue, 16 Aug 2005 14:36:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org But the spec says: 6.6. Format Errors The following two explicit violations of PDU layout rules are format errors: a) Illegal contents of any PDU header field except the Opcode (legal values are specified in Section 10 iSCSI PDU Formats). b) Inconsistent field contents (consistent field contents are specified in Section 10 iSCSI PDU Formats). Format errors indicate a major implementation flaw in one of the parties. When a target or an initiator receives an iSCSI PDU with a format error, it MUST immediately terminate all transport connections in the session either with a connection close or with a connection reset and escalate the format error to session recovery (see Section 6.1.4.4 Session Recovery). Eddy ----- Original Message ----- From: "John Hufferd" To: "Eddy Quicksall" ; ; "William Studenmund" Sent: Tuesday, August 16, 2005 12:57 PM Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data We neither allow nor disallow it. It has no effect on interoperability as long as the spec is followed by the target. This is stuff that developers all do when first developing code that will involve moving from one level to another. It is best that we continue our current direction. It hurts no one, and is useful to many. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net] Sent: Tuesday, August 16, 2005 5:19 AM To: John Hufferd; ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data I didn't know we (the RFC) allowed for probing with invalid values. Isn't that part of the reason the RFC has so many MUST's? Take the recent use of 0xFFFFFFFF for the ITT. It is now being made clear that the initiator must not use that except for NOP's. If probing with invalid values is allowed, it should be cleared up in draft-ietf-ips-iscsi-impl-guide-00.txt. Eddy ----- Original Message ----- From: "John Hufferd" To: "Eddy Quicksall" ; ; "William Studenmund" Sent: Monday, August 15, 2005 5:28 PM Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data I expect we should leave it up to the initiator, since they might be probing the target with vendor specific items, which the target can not handle, or early implementations of still un-standardized features. Not that we should pre approve any of these, but we should just leave it as it is, and let the initiator deal with it. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Eddy Quicksall Sent: Monday, August 15, 2005 1:21 PM To: ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data BTW, I didn't mean to duck your original issue and that is "what sense data should be given for particular errors". I think there are people on the reflector that are familiar with that issue so I will look forward to those responses. Thanks, Eddy ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Monday, August 15, 2005 4:03 PM Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data >>>>>> "Eddy" == Eddy Quicksall >>>>>> writes: > > >>> We already have examples in RFC 3720 where we report SCSI Sense > >>> data in > Eddy> response to iSCSI protocol confusion. > > Eddy> I've always wondered about these kind of examples. Exactly what > Eddy> is the initiator supposed to do when it finds that the target > Eddy> has reported a protocol error? > > Right. > > I can't see any sense in spending effort on complicated rules for > protocol errors. Just nuke the session and walk away. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 17 10:46:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PB2-0000nr-Pn; Wed, 17 Aug 2005 10:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58h8-0003LK-VT for ips@megatron.ietf.org; Tue, 16 Aug 2005 17:10:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12594 for ; Tue, 16 Aug 2005 17:10:00 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E59GU-0007DP-0N for ips@ietf.org; Tue, 16 Aug 2005 17:46:38 -0400 Received: from dm-prc-01.singapore.sun.com ([129.158.71.109]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7GL9tte010330 for ; Tue, 16 Aug 2005 14:09:56 -0700 (PDT) Received: from sandieji.prc.sun.com (sandieji.PRC.Sun.COM [129.158.215.122]) by dm-prc-01.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL, v2.2) with ESMTP id j7GLBFZv009844 for ; Wed, 17 Aug 2005 05:11:15 +0800 (SGT) Received: from [127.0.0.1] (dhcp-ubrm05-50-127.Central.Sun.COM [129.147.50.127]) by sandieji.prc.sun.com (8.13.2+Sun/8.13.2) with ESMTP id j7GL9obX015007; Wed, 17 Aug 2005 05:09:53 +0800 (CST) Message-ID: <43025617.9040908@Sun.COM> Date: Wed, 17 Aug 2005 05:09:43 +0800 From: "Javen.Wu" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 17 Aug 2005 10:46:00 -0400 Cc: Tim Szeto Subject: [Ips] Question about iSCSI 3rd party reservation. X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi guys, >3d party reservation is mandatory implement in SPC3. > In fact, I want to know how the 3rd party reserve work for iSCSI. > U know, if application wanna issue a 3rd party reservation. he will > birng a 3rd party device ID in CDB. > How to translate the 3rd party ID to a real node name? > I suspect if a parellel SCSI user wanna issue a 3rd reservation, he will > fill Target ID to the 3rd device ID field. > And if a FC user wanan issue a 3rd reservation, he will fill WWN to the > 3rd device ID field. > So I guess if a iSCSI user wanna issue 3rd reservation, the CDB of > reserve(10) will bring iqn name. > I am not sure my guess is correct,just a guess. > > Your reponse is appreciated. I just wanna discuss SCSI protocol implementation > in iSCSI target emulation. > Thx again! > BR > Javen _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 17 11:07:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PVa-0007SY-Ec; Wed, 17 Aug 2005 11:07:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PVX-0007SR-KM for ips@megatron.ietf.org; Wed, 17 Aug 2005 11:07:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06331 for ; Wed, 17 Aug 2005 11:07:09 -0400 (EDT) Received: from relay2.mail.twtelecom.net ([216.54.204.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Q55-0002F4-O6 for ips@ietf.org; Wed, 17 Aug 2005 11:43:56 -0400 Received: from saturn.p3corpnet.pivot3.com (207-114-252-60.gen.twtelecom.net [207.114.252.60]) by relay2.mail.twtelecom.net (Postfix) with ESMTP id E7A54C229 for ; Wed, 17 Aug 2005 10:06:58 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Question about iSCSI 3rd party reservation. Date: Wed, 17 Aug 2005 10:06:55 -0500 Message-ID: Thread-Topic: [Ips] Question about iSCSI 3rd party reservation. Thread-Index: AcWjOuGpeXTPkviXRg6oy7sbPMsYhAAAZ+NQ From: "Galloway, Bill" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org 3d party reservations are not required in SPC3. The reserve/release commands are actually obsolete in SPC3. The replacement is persistent reserve/release which is not required by SPC3 and is optional in SBC2. Bill Galloway > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Javen.Wu > Sent: Tuesday, August 16, 2005 4:10 PM > To: ips@ietf.org > Cc: Tim Szeto > Subject: [Ips] Question about iSCSI 3rd party reservation. >=20 > Hi guys, > >3d party reservation is mandatory implement in SPC3. > > In fact, I want to know how the 3rd party reserve work for iSCSI. > > U know, if application wanna issue a 3rd party reservation. he will=20 > > birng a 3rd party device ID in CDB. > > How to translate the 3rd party ID to a real node name? > > I suspect if a parellel SCSI user wanna issue a 3rd=20 > reservation, he will=20 > > fill Target ID to the 3rd device ID field. > > And if a FC user wanan issue a 3rd reservation, he will=20 > fill WWN to the=20 > > 3rd device ID field. > > So I guess if a iSCSI user wanna issue 3rd reservation, the CDB of=20 > > reserve(10) will bring iqn name. > > I am not sure my guess is correct,just a guess. > >=20 > > Your reponse is appreciated. I just wanna discuss SCSI=20 > protocol implementation=20 > > in iSCSI target emulation. > > Thx again! > > BR > > Javen >=20 >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 17 12:16:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5QYx-0007g0-Rq; Wed, 17 Aug 2005 12:14:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5QYw-0007fv-UD for ips@megatron.ietf.org; Wed, 17 Aug 2005 12:14:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09608 for ; Wed, 17 Aug 2005 12:14:44 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5R8T-0004DC-20 for ips@ietf.org; Wed, 17 Aug 2005 12:51:32 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7HGEHHT004182 for ; Wed, 17 Aug 2005 12:14:17 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7HGEHKl269810 for ; Wed, 17 Aug 2005 12:14:17 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7HGE74D020982 for ; Wed, 17 Aug 2005 12:14:07 -0400 Received: from [9.56.227.90] (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7HGE7Ao020294 for ; Wed, 17 Aug 2005 12:14:07 -0400 Importance: Normal MIME-Version: 1.0 To: ips@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Wed, 17 Aug 2005 09:13:55 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_08072005|August 07, 2005) at 08/17/2005 12:14:06, Serialize complete at 08/17/2005 12:14:06 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ips] iSER draft update X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I have updated the iSER draft incorporating the changes as suggested in draft-hufferd-iser-ib-00.txt plus other changes that were intended but were omitted in the Hufferd draft. (See my previous note to the reflector.) With thanks to Julian Satran, you can download both the text version (draft-ietf-ips-iser-05-candidate.txt) and a PDF version showing the changes (draft-ietf-ips-iser-05-candidate.pdf) in his website at http://www.haifa.il.ibm.com/satran/ips/ Note that these are not official IETF releases and are merely interim versions for discussion purposes only. Mike _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 17 13:01:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5RHn-0005EI-03; Wed, 17 Aug 2005 13:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5RHk-0005Dx-DX for ips@megatron.ietf.org; Wed, 17 Aug 2005 13:01:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11662 for ; Wed, 17 Aug 2005 13:01:01 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5RrH-0005P5-FF for ips@ietf.org; Wed, 17 Aug 2005 13:37:50 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id F14518708B; Wed, 17 Aug 2005 13:00:47 -0400 (EDT) In-Reply-To: <43025617.9040908@Sun.COM> References: <43025617.9040908@Sun.COM> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] Question about iSCSI 3rd party reservation. Date: Wed, 17 Aug 2005 10:00:36 -0700 To: "Javen.Wu" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Tim Szeto , 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="===============1517373976==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1517373976== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--38051311" Content-Transfer-Encoding: 7bit --Apple-Mail-1--38051311 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 16, 2005, at 2:09 PM, Javen.Wu wrote: > Hi guys, >> 3d party reservation is mandatory implement in SPC3. As Bill noted, this statement is incorrect. What is correct is that, according to SPC2, if you implement the RESERVE(10) command, you also must implement 3rd party reservations. >> In fact, I want to know how the 3rd party reserve work for iSCSI. >> U know, if application wanna issue a 3rd party reservation. he will >> birng a 3rd party device ID in CDB. >> How to translate the 3rd party ID to a real node name? You don't. And that's the problem with RESERVE(10). >> I suspect if a parellel SCSI user wanna issue a 3rd reservation, he >> will fill Target ID to the 3rd device ID field. >> And if a FC user wanan issue a 3rd reservation, he will fill WWN to >> the 3rd device ID field. >> So I guess if a iSCSI user wanna issue 3rd reservation, the CDB of >> reserve(10) will bring iqn name. Technically the WWN is in the parameter list, which is transfered as part of the data phase. But you are correct that the command should carry the iqn name. And the problem with RESERVE(10) is that the parameter list can only be 8 bytes, which won't fit an iqn name. And that's why our (Wasabi's) target does not implement RESERVE(10) & RELEASE(10). It will never work right. >> I am not sure my guess is correct,just a guess. >> Your reponse is appreciated. I just wanna discuss SCSI protocol >> implementation in iSCSI target emulation. >> Thx again! --Apple-Mail-1--38051311 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDA209DJT2Egh26K0RAnzkAJoD0oE6leU8g5ZBhsUHi0hGAYectwCfV+9L N/sqIKmp6YL+2a0ug/0/gSU= =wFkT -----END PGP SIGNATURE----- --Apple-Mail-1--38051311-- --===============1517373976== 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 --===============1517373976==-- From ips-bounces@ietf.org Wed Aug 17 13:32:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5RmN-0005Vr-L3; Wed, 17 Aug 2005 13:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5RmM-0005Vm-70 for ips@megatron.ietf.org; Wed, 17 Aug 2005 13:32:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13638 for ; Wed, 17 Aug 2005 13:32:40 -0400 (EDT) Received: from f112.brocade.com ([66.243.153.112] helo=blasphemy.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5SLs-0006MR-JS for ips@ietf.org; Wed, 17 Aug 2005 14:09:27 -0400 Received: from hq-ex-5.corp.brocade.com (hq-ex-5 [192.168.38.35]) by blasphemy.brocade.com (Postfix) with ESMTP id 302B61430F; Wed, 17 Aug 2005 10:32:22 -0700 (PDT) Received: from hq-ex-6.corp.brocade.com ([192.168.38.36]) by hq-ex-5.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Aug 2005 10:32:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data Date: Wed, 17 Aug 2005 10:32:21 -0700 Message-ID: Thread-Topic: [Ips] Question about invalid PDUs and SCSI sense data Thread-Index: AcWikW69Kqfixqi1TkiCxYBXzkw8RgAvspcA From: "John Hufferd" To: "Eddy Quicksall" , , "William Studenmund" X-OriginalArrivalTime: 17 Aug 2005 17:32:21.0957 (UTC) FILETIME=[9FDB8750:01C5A351] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Eddy, Perhaps I was too general with my response. You asked the fairly general question: Eddy> I've always wondered about these kind of examples. Exactly what Eddy> is the initiator supposed to do when it finds that the target Eddy> has reported a protocol error? My somewhat general response reflected my understanding of the Reason Codes of the Reject command. On the other hand in you last note you clearly identified a specific item, which explicitly also states what the Initiator or Target MUST do. So since that seems to be clear, and you now know what I was focused upon, perhaps everything is OK..? . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net]=20 Sent: Tuesday, August 16, 2005 11:36 AM To: John Hufferd; ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data But the spec says: 6.6. Format Errors The following two explicit violations of PDU layout rules are format errors: a) Illegal contents of any PDU header field except the Opcode (legal values are specified in Section 10 iSCSI PDU Formats). b) Inconsistent field contents (consistent field contents are specified in Section 10 iSCSI PDU Formats). Format errors indicate a major implementation flaw in one of the parties. When a target or an initiator receives an iSCSI PDU with a format error, it MUST immediately terminate all transport connections in the session either with a connection close or with a connection reset and escalate the format error to session recovery (see Section 6.1.4.4 Session Recovery). Eddy ----- Original Message -----=20 From: "John Hufferd" To: "Eddy Quicksall" ;=20 ; "William Studenmund" Sent: Tuesday, August 16, 2005 12:57 PM Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data We neither allow nor disallow it. It has no effect on interoperability as long as the spec is followed by the target. This is stuff that developers all do when first developing code that will involve moving from one level to another. It is best that we continue our current direction. It hurts no one, and is useful to many. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net] Sent: Tuesday, August 16, 2005 5:19 AM To: John Hufferd; ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data I didn't know we (the RFC) allowed for probing with invalid values. Isn't that part of the reason the RFC has so many MUST's? Take the recent use of 0xFFFFFFFF for the ITT. It is now being made clear that the initiator must not use that except for NOP's. If probing with invalid values is allowed, it should be cleared up in draft-ietf-ips-iscsi-impl-guide-00.txt. Eddy ----- Original Message -----=20 From: "John Hufferd" To: "Eddy Quicksall" ; ; "William Studenmund" Sent: Monday, August 15, 2005 5:28 PM Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data I expect we should leave it up to the initiator, since they might be probing the target with vendor specific items, which the target can not handle, or early implementations of still un-standardized features. Not that we should pre approve any of these, but we should just leave it as it is, and let the initiator deal with it. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Eddy Quicksall Sent: Monday, August 15, 2005 1:21 PM To: ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data BTW, I didn't mean to duck your original issue and that is "what sense data should be given for particular errors". I think there are people on the reflector that are familiar with that issue so I will look forward to those responses. Thanks, Eddy ----- Original Message -----=20 From: "Paul Koning" To: Cc: Sent: Monday, August 15, 2005 4:03 PM Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data >>>>>> "Eddy" =3D=3D Eddy Quicksall >>>>>> writes: > > >>> We already have examples in RFC 3720 where we report SCSI Sense > >>> data in > Eddy> response to iSCSI protocol confusion. > > Eddy> I've always wondered about these kind of examples. Exactly what > Eddy> is the initiator supposed to do when it finds that the target > Eddy> has reported a protocol error? > > Right. > > I can't see any sense in spending effort on complicated rules for > protocol errors. Just nuke the session and walk away. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 17 15:31:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Tcz-0003Pb-Ce; Wed, 17 Aug 2005 15:31:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Tcx-0003O8-NS for ips@megatron.ietf.org; Wed, 17 Aug 2005 15:31:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19947 for ; Wed, 17 Aug 2005 15:31:05 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5UCY-00014c-Sf for ips@ietf.org; Wed, 17 Aug 2005 16:07:55 -0400 Received: from ivvt2dxrc11 (unknown[64.238.111.98]) by comcast.net (sccrmhc12) with SMTP id <20050817193053012004uefge>; Wed, 17 Aug 2005 19:30:53 +0000 Message-ID: <001a01c5a362$2ed4fd00$a001a8c0@ivivity.com> From: "Eddy Quicksall" To: "John Hufferd" , , "William Studenmund" References: Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data Date: Wed, 17 Aug 2005 15:30:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Yea, it is fine with me. I think this thread was William's and I just was putting in my 2 cents worth. I think the main question was lost in the responses ... he may want to re-ask it. Eddy ----- Original Message ----- From: "John Hufferd" To: "Eddy Quicksall" ; ; "William Studenmund" Sent: Wednesday, August 17, 2005 1:32 PM Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data Eddy, Perhaps I was too general with my response. You asked the fairly general question: Eddy> I've always wondered about these kind of examples. Exactly what Eddy> is the initiator supposed to do when it finds that the target Eddy> has reported a protocol error? My somewhat general response reflected my understanding of the Reason Codes of the Reject command. On the other hand in you last note you clearly identified a specific item, which explicitly also states what the Initiator or Target MUST do. So since that seems to be clear, and you now know what I was focused upon, perhaps everything is OK..? . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net] Sent: Tuesday, August 16, 2005 11:36 AM To: John Hufferd; ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data But the spec says: 6.6. Format Errors The following two explicit violations of PDU layout rules are format errors: a) Illegal contents of any PDU header field except the Opcode (legal values are specified in Section 10 iSCSI PDU Formats). b) Inconsistent field contents (consistent field contents are specified in Section 10 iSCSI PDU Formats). Format errors indicate a major implementation flaw in one of the parties. When a target or an initiator receives an iSCSI PDU with a format error, it MUST immediately terminate all transport connections in the session either with a connection close or with a connection reset and escalate the format error to session recovery (see Section 6.1.4.4 Session Recovery). Eddy ----- Original Message ----- From: "John Hufferd" To: "Eddy Quicksall" ; ; "William Studenmund" Sent: Tuesday, August 16, 2005 12:57 PM Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data We neither allow nor disallow it. It has no effect on interoperability as long as the spec is followed by the target. This is stuff that developers all do when first developing code that will involve moving from one level to another. It is best that we continue our current direction. It hurts no one, and is useful to many. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall_iVivity_iSCSI@Comcast.net] Sent: Tuesday, August 16, 2005 5:19 AM To: John Hufferd; ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data I didn't know we (the RFC) allowed for probing with invalid values. Isn't that part of the reason the RFC has so many MUST's? Take the recent use of 0xFFFFFFFF for the ITT. It is now being made clear that the initiator must not use that except for NOP's. If probing with invalid values is allowed, it should be cleared up in draft-ietf-ips-iscsi-impl-guide-00.txt. Eddy ----- Original Message ----- From: "John Hufferd" To: "Eddy Quicksall" ; ; "William Studenmund" Sent: Monday, August 15, 2005 5:28 PM Subject: RE: [Ips] Question about invalid PDUs and SCSI sense data I expect we should leave it up to the initiator, since they might be probing the target with vendor specific items, which the target can not handle, or early implementations of still un-standardized features. Not that we should pre approve any of these, but we should just leave it as it is, and let the initiator deal with it. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Eddy Quicksall Sent: Monday, August 15, 2005 1:21 PM To: ips@ietf.org; William Studenmund Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data BTW, I didn't mean to duck your original issue and that is "what sense data should be given for particular errors". I think there are people on the reflector that are familiar with that issue so I will look forward to those responses. Thanks, Eddy ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Monday, August 15, 2005 4:03 PM Subject: Re: [Ips] Question about invalid PDUs and SCSI sense data >>>>>> "Eddy" == Eddy Quicksall >>>>>> writes: > > >>> We already have examples in RFC 3720 where we report SCSI Sense > >>> data in > Eddy> response to iSCSI protocol confusion. > > Eddy> I've always wondered about these kind of examples. Exactly what > Eddy> is the initiator supposed to do when it finds that the target > Eddy> has reported a protocol error? > > Right. > > I can't see any sense in spending effort on complicated rules for > protocol errors. Just nuke the session and walk away. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 17 20:33:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5YLS-0005F2-6F; Wed, 17 Aug 2005 20:33:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5YLQ-0005Eu-Ul; Wed, 17 Aug 2005 20:33:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14822; Wed, 17 Aug 2005 20:33:18 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Yv1-0003wP-UK; Wed, 17 Aug 2005 21:10:10 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7I0Ww4I007195; Wed, 17 Aug 2005 20:32:58 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7I0WwFv244446; Wed, 17 Aug 2005 20:32:58 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7I0WwNC021661; Wed, 17 Aug 2005 20:32:58 -0400 Received: from [9.56.227.90] (d01ml604.pok.ibm.com [9.56.227.90]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7I0WwsH021658; Wed, 17 Aug 2005 20:32:58 -0400 To: William Studenmund MIME-Version: 1.0 Subject: Re: [Ips] Question about iSCSI 3rd party reservation. X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Jim Hafner Date: Wed, 17 Aug 2005 20:32:56 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_08072005|August 07, 2005) at 08/17/2005 20:32:57 Content-Type: multipart/mixed; boundary="=_mixed 0002FF5688257061_=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: Tim Szeto , ips@ietf.org, ips-bounces@ietf.org, "Javen.Wu" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --=_mixed 0002FF5688257061_= Content-Type: multipart/alternative; boundary="=_alternative 0002FF5788257061_=" --=_alternative 0002FF5788257061_= Content-Type: text/plain; charset="US-ASCII" The "ALIAS" commands in SPC-3 is designed exactly to solve this problem of naming a third party in a small field when the name is larger than can fit in that field. Support for this command is optional, but I would expect that an implementation of RESERVE/RELEASE(10) will support the ALIAS commands as well ... or else "it won't work". Jim Hafner/Almaden/IBM Tel: (408) 927-1892, Fax: (408) 927-3030 (t/l 457) Email:hafner@almaden.ibm.com William Studenmund Sent by: ips-bounces@ietf.org 08/17/2005 10:00 AM To: "Javen.Wu" cc: Tim Szeto , ips@ietf.org Subject: Re: [Ips] Question about iSCSI 3rd party reservation. On Aug 16, 2005, at 2:09 PM, Javen.Wu wrote: > Hi guys, >> 3d party reservation is mandatory implement in SPC3. As Bill noted, this statement is incorrect. What is correct is that, according to SPC2, if you implement the RESERVE(10) command, you also must implement 3rd party reservations. >> In fact, I want to know how the 3rd party reserve work for iSCSI. >> U know, if application wanna issue a 3rd party reservation. he will >> birng a 3rd party device ID in CDB. >> How to translate the 3rd party ID to a real node name? You don't. And that's the problem with RESERVE(10). >> I suspect if a parellel SCSI user wanna issue a 3rd reservation, he >> will fill Target ID to the 3rd device ID field. >> And if a FC user wanan issue a 3rd reservation, he will fill WWN to >> the 3rd device ID field. >> So I guess if a iSCSI user wanna issue 3rd reservation, the CDB of >> reserve(10) will bring iqn name. Technically the WWN is in the parameter list, which is transfered as part of the data phase. But you are correct that the command should carry the iqn name. And the problem with RESERVE(10) is that the parameter list can only be 8 bytes, which won't fit an iqn name. And that's why our (Wasabi's) target does not implement RESERVE(10) & RELEASE(10). It will never work right. >> I am not sure my guess is correct,just a guess. >> Your reponse is appreciated. I just wanna discuss SCSI protocol >> implementation in iSCSI target emulation. >> Thx again! _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips #### PGP.sig has been removed from this note on August 17, 2005 by Jim Hafner --=_alternative 0002FF5788257061_= Content-Type: text/html; charset="US-ASCII"
The "ALIAS" commands in SPC-3 is designed exactly to solve this problem of naming a third party in a small field when the name is larger than can fit in that field.  Support for this command is optional, but I would expect that an implementation of RESERVE/RELEASE(10) will support the ALIAS commands as well ... or else "it won't work".

Jim Hafner/Almaden/IBM
Tel: (408) 927-1892, Fax: (408) 927-3030 (t/l 457)
Email:hafner@almaden.ibm.com


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

08/17/2005 10:00 AM

       
        To:        "Javen.Wu" <Javen.Wu@Sun.COM>
        cc:        Tim Szeto <Tim.Szeto@Sun.COM>, ips@ietf.org
        Subject:        Re: [Ips] Question about iSCSI 3rd party reservation.



On Aug 16, 2005, at 2:09 PM, Javen.Wu wrote:
> Hi guys,
>> 3d party reservation is mandatory implement in SPC3.
As Bill noted, this statement is incorrect.
What is correct is that, according to SPC2, if you implement the
RESERVE(10) command, you also must implement 3rd party reservations.
>> In fact, I want to know how the 3rd party reserve work for iSCSI.
>> U know, if application wanna issue a 3rd party reservation. he will
>> birng a  3rd party device ID in CDB.
>> How to translate the 3rd party ID to a real node name?
You don't. And that's the problem with RESERVE(10).
>> I suspect if a parellel SCSI user wanna issue a 3rd reservation, he
>> will fill Target ID to the 3rd device ID field.
>> And if a FC user wanan issue a 3rd reservation, he will fill WWN to
>> the 3rd device ID field.
>> So I guess if a iSCSI user wanna issue 3rd reservation, the CDB of
>> reserve(10) will bring iqn name.
Technically the WWN is in the parameter list, which is transfered as
part of the data phase. But you are correct that the command should
carry the iqn name. And the problem with RESERVE(10) is that the
parameter list can only be 8 bytes, which won't fit an iqn name.
And that's why our (Wasabi's) target does not implement RESERVE(10) &
RELEASE(10). It will never work right.
>> I am not sure my guess is correct,just a guess.
>> Your reponse is appreciated. I just wanna discuss SCSI protocol
>> implementation in iSCSI target emulation.
>> Thx again!

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


#### PGP.sig has been removed from this note on August 17, 2005 by Jim Hafner

--=_alternative 0002FF5788257061_=-- --=_mixed 0002FF5688257061_= Content-Type: application/octet-stream; name="PGP.sig" Content-Disposition: attachment; filename="PGP.sig" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjIuMyAoRGFy d2luKQ0KDQppRDhEQlFGREEyMDlESlQyRWdoMjZLMFJBbnprQUpvRDBvRTZsZVU4ZzVaQmhzVUhp MGhHQVllY3R3Q2ZWKzlMDQpOL3NxSUttcDZZTCsyYTB1Zy8wL2dTVT0NCj13RmtUDQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg0K --=_mixed 0002FF5688257061_= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_mixed 0002FF5688257061_=-- From ips-bounces@ietf.org Thu Aug 18 11:08:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5m0J-0003DI-41; Thu, 18 Aug 2005 11:08:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5m0H-0003D1-0r for ips@megatron.ietf.org; Thu, 18 Aug 2005 11:08:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11498 for ; Thu, 18 Aug 2005 11:08:22 -0400 (EDT) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5ma1-0003pw-DK for ips@ietf.org; Thu, 18 Aug 2005 11:45:22 -0400 Received: from localhost.localdomain (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j7IF8G4r012544; Thu, 18 Aug 2005 11:08:16 -0400 (EDT) Subject: Re: [Ips] Question about iSCSI 3rd party reservation. From: Ming Zhang To: William Studenmund In-Reply-To: References: <43025617.9040908@Sun.COM> Content-Type: text/plain Organization: no-dole-available Date: Thu, 18 Aug 2005 11:08:15 -0400 Message-Id: <1124377696.5544.40.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Tim Szeto , ips@ietf.org, "Javen.Wu" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org then how can u support those cluster service? ming On Wed, 2005-08-17 at 10:00 -0700, William Studenmund wrote: > On Aug 16, 2005, at 2:09 PM, Javen.Wu wrote: > > > Hi guys, > >> 3d party reservation is mandatory implement in SPC3. > > As Bill noted, this statement is incorrect. > > What is correct is that, according to SPC2, if you implement the > RESERVE(10) command, you also must implement 3rd party reservations. > > >> In fact, I want to know how the 3rd party reserve work for iSCSI. > >> U know, if application wanna issue a 3rd party reservation. he will > >> birng a 3rd party device ID in CDB. > >> How to translate the 3rd party ID to a real node name? > > You don't. And that's the problem with RESERVE(10). > > >> I suspect if a parellel SCSI user wanna issue a 3rd reservation, he > >> will fill Target ID to the 3rd device ID field. > >> And if a FC user wanan issue a 3rd reservation, he will fill WWN to > >> the 3rd device ID field. > >> So I guess if a iSCSI user wanna issue 3rd reservation, the CDB of > >> reserve(10) will bring iqn name. > > Technically the WWN is in the parameter list, which is transfered as > part of the data phase. But you are correct that the command should > carry the iqn name. And the problem with RESERVE(10) is that the > parameter list can only be 8 bytes, which won't fit an iqn name. > > And that's why our (Wasabi's) target does not implement RESERVE(10) & > RELEASE(10). It will never work right. > > >> I am not sure my guess is correct,just a guess. > >> Your reponse is appreciated. I just wanna discuss SCSI protocol > >> implementation in iSCSI target emulation. > >> Thx again! > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 18 11:35:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mQE-0002vC-Hn; Thu, 18 Aug 2005 11:35:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mQC-0002v5-KO for ips@megatron.ietf.org; Thu, 18 Aug 2005 11:35:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12926 for ; Thu, 18 Aug 2005 11:35:10 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5mzx-0004eO-OE for ips@ietf.org; Thu, 18 Aug 2005 12:12:11 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id F403C870AA; Thu, 18 Aug 2005 11:35:05 -0400 (EDT) In-Reply-To: <1124377696.5544.40.camel@localhost.localdomain> References: <43025617.9040908@Sun.COM> <1124377696.5544.40.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: From: William Studenmund Subject: Re: [Ips] Question about iSCSI 3rd party reservation. Date: Thu, 18 Aug 2005 08:34:59 -0700 To: mingz@ele.uri.edu X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Tim Szeto , ips@ietf.org, "Javen.Wu" 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="===============1824641675==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1824641675== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-43211748" Content-Transfer-Encoding: 7bit --Apple-Mail-1-43211748 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 18, 2005, at 8:08 AM, Ming Zhang wrote: > then how can u support those cluster service? RESERVE(6)/RELEASE(6) and Persistent reservations. Take care, Bill --Apple-Mail-1-43211748 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDBKqpDJT2Egh26K0RAo5iAKCL9O+CFeDzGCR+BuSdIygqDCVQtACeKsZD M+3NQiJKeWel0XgDrxTlYBE= =BZ9i -----END PGP SIGNATURE----- --Apple-Mail-1-43211748-- --===============1824641675== 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 --===============1824641675==-- From ips-bounces@ietf.org Thu Aug 18 12:25:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nCz-0001p5-AC; Thu, 18 Aug 2005 12:25:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nCx-0001oU-M6 for ips@megatron.ietf.org; Thu, 18 Aug 2005 12:25:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15865 for ; Thu, 18 Aug 2005 12:25:33 -0400 (EDT) Received: from zproxy.gmail.com ([64.233.162.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nmj-0006G2-9b for ips@ietf.org; Thu, 18 Aug 2005 13:02:34 -0400 Received: by zproxy.gmail.com with SMTP id i1so310756nzh for ; Thu, 18 Aug 2005 09:25:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FpaE8ofbcD3tQEhv/qck6xPtiRUUquknJf5rK4ZcbG6W7MK+sL7t3/sDGnzdV3cUpIAx8b9ciZvlz/4hr2oGAxNkmts91OQ9ukiFA8iWOPw/YkvWP7bgp80HDAfOKFIdqYedY2m85KjlvOdijC4g7XOG4ywrXSVzLjtjC2K3axo= Received: by 10.36.119.1 with SMTP id r1mr1709948nzc; Thu, 18 Aug 2005 09:25:24 -0700 (PDT) Received: by 10.37.22.70 with HTTP; Thu, 18 Aug 2005 09:25:20 -0700 (PDT) Message-ID: <8320074d0508180925358aba7d@mail.gmail.com> Date: Thu, 18 Aug 2005 21:55:20 +0530 From: Rohan Sen To: ISCSI Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Subject: [Ips] SendTargets sent with other key in Text Request X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org What should the Target do if it receives a Text Request PDU in Discover Session containing the following keys : " - SendTargets=3DAll" " - MaxRecvDataSegmentLength=3D1000" (invalid as per rfc3720 Appendix D Page 229) Should the target send a Reject PDU stating Protocol Error but not close the connection or should it simply close the connection without sending any ISCSI PDU ? --=20 thanks, Rohan Sen _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 18 12:29:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nH4-0003PM-Aq; Thu, 18 Aug 2005 12:29:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nH2-0003PH-UQ for ips@megatron.ietf.org; Thu, 18 Aug 2005 12:29:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16135 for ; Thu, 18 Aug 2005 12:29:46 -0400 (EDT) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nqn-0006Pk-Ht for ips@ietf.org; Thu, 18 Aug 2005 13:06:47 -0400 Received: from localhost.localdomain (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j7IGTg4r014928; Thu, 18 Aug 2005 12:29:42 -0400 (EDT) Subject: Re: [Ips] Question about iSCSI 3rd party reservation. From: Ming Zhang To: William Studenmund In-Reply-To: References: <43025617.9040908@Sun.COM> <1124377696.5544.40.camel@localhost.localdomain> Content-Type: text/plain Organization: no-dole-available Date: Thu, 18 Aug 2005 12:29:42 -0400 Message-Id: <1124382582.5544.42.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Tim Szeto , ips@ietf.org, "Javen.Wu" X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org :P yes, i forgot u can support RR6 only instead of RR10. thanks! Ming On Thu, 2005-08-18 at 08:34 -0700, William Studenmund wrote: > On Aug 18, 2005, at 8:08 AM, Ming Zhang wrote: > > > then how can u support those cluster service? > > RESERVE(6)/RELEASE(6) and Persistent reservations. > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 18 12:31:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nIM-0003aW-3k; Thu, 18 Aug 2005 12:31:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nIK-0003Zp-Lq for ips@megatron.ietf.org; Thu, 18 Aug 2005 12:31:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16187 for ; Thu, 18 Aug 2005 12:31:06 -0400 (EDT) Received: from leviathan.ele.uri.edu ([131.128.51.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5ns7-0006RV-8q for ips@ietf.org; Thu, 18 Aug 2005 13:08:07 -0400 Received: from localhost.localdomain (leviathan [131.128.51.64]) by leviathan.ele.uri.edu (8.12.9/8.12.9) with ESMTP id j7IGV44r014962; Thu, 18 Aug 2005 12:31:04 -0400 (EDT) Subject: Re: [Ips] Question about iSCSI 3rd party reservation. From: Ming Zhang To: "Javen.Wu" In-Reply-To: <4304AB66.6040003@Sun.COM> References: <43025617.9040908@Sun.COM> <1124377696.5544.40.camel@localhost.localdomain> <4304AB66.6040003@Sun.COM> Content-Type: text/plain Organization: no-dole-available Date: Thu, 18 Aug 2005 12:31:03 -0400 Message-Id: <1124382664.5544.45.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: Tim Szeto , ips@ietf.org, William Studenmund X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mingz@ele.uri.edu List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org yes, u are right. but my understanding is that new Persistent reservation in/out is a super set of rr. ming On Thu, 2005-08-18 at 23:38 +0800, Javen.Wu wrote: > Please refer to SPC3 revision 23 Annex B. Persistent reservation can > replace RESERVE/RELEASE functionality. > Ming Zhang wrote: > > >then how can u support those cluster service? > > > >ming > > > >On Wed, 2005-08-17 at 10:00 -0700, William Studenmund wrote: > > > > > >>On Aug 16, 2005, at 2:09 PM, Javen.Wu wrote: > >> > >> > >> > >>>Hi guys, > >>> > >>> > >>>>3d party reservation is mandatory implement in SPC3. > >>>> > >>>> > >>As Bill noted, this statement is incorrect. > >> > >>What is correct is that, according to SPC2, if you implement the > >>RESERVE(10) command, you also must implement 3rd party reservations. > >> > >> > >> > >>>>In fact, I want to know how the 3rd party reserve work for iSCSI. > >>>>U know, if application wanna issue a 3rd party reservation. he will > >>>>birng a 3rd party device ID in CDB. > >>>>How to translate the 3rd party ID to a real node name? > >>>> > >>>> > >>You don't. And that's the problem with RESERVE(10). > >> > >> > >> > >>>>I suspect if a parellel SCSI user wanna issue a 3rd reservation, he > >>>>will fill Target ID to the 3rd device ID field. > >>>>And if a FC user wanan issue a 3rd reservation, he will fill WWN to > >>>>the 3rd device ID field. > >>>>So I guess if a iSCSI user wanna issue 3rd reservation, the CDB of > >>>>reserve(10) will bring iqn name. > >>>> > >>>> > >>Technically the WWN is in the parameter list, which is transfered as > >>part of the data phase. But you are correct that the command should > >>carry the iqn name. And the problem with RESERVE(10) is that the > >>parameter list can only be 8 bytes, which won't fit an iqn name. > >> > >>And that's why our (Wasabi's) target does not implement RESERVE(10) & > >>RELEASE(10). It will never work right. > >> > >> > >> > >>>>I am not sure my guess is correct,just a guess. > >>>>Your reponse is appreciated. I just wanna discuss SCSI protocol > >>>>implementation in iSCSI target emulation. > >>>>Thx again! > >>>> > >>>> > >>_______________________________________________ > >>Ips mailing list > >>Ips@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ips > >> > >> > > > > > > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 18 14:31:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pAk-0001I5-Ty; Thu, 18 Aug 2005 14:31:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pAj-0001I0-Id for ips@megatron.ietf.org; Thu, 18 Aug 2005 14:31:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22260 for ; Thu, 18 Aug 2005 14:31:24 -0400 (EDT) Received: from ccerelbas04.cce.hp.com ([161.114.21.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5pkV-0001Wn-WF for ips@ietf.org; Thu, 18 Aug 2005 15:08:25 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.58]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id 3DC222000464 for ; Thu, 18 Aug 2005 13:31:14 -0500 (CDT) Received: from cceexc17.americas.cpqcorp.net ([16.81.1.15]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 13:31:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Re: ISID and Discovery Re:draft-ietf-ips-iscsi-impl-guide-00.txt Date: Thu, 18 Aug 2005 13:31:11 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C60A894432@cceexc17.americas.cpqcorp.net> Thread-Topic: [Ips] Re: ISID and Discovery Re:draft-ietf-ips-iscsi-impl-guide-00.txt Thread-Index: AcWTBfyc/kY2qrRzS8SuFD4Qw3HRBgQQFn5A From: "Elliott, Robert (Server Storage)" To: X-OriginalArrivalTime: 18 Aug 2005 18:31:12.0670 (UTC) FILETIME=[02BD53E0:01C5A423] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Mallikarjun C. > Sent: Wednesday, July 27, 2005 6:45 PM > To: IPS > Subject: Re: [Ips] Re: ISID and Discovery=20 >=20 > Bill, >=20 > > So while the RFC permits zero, SAM does not. >=20 > Thanks for pointing this out. Rob Elliott though noted the following=20 > offline on my prompt: a) That is just an informative annex in SAM-nn,=20 > not normative, so other documents can override it, and b) The=20 > existing SAM-nn text is historical (until iSCSI rev13 or so, we=20 > required it to be between 1-65535). Rob also volunteered to move a=20 > T10 proposal to sync up the SAM-4 wording to RFC 3720 (thanks Rob!). T10 proposal 05-301r0 has been posted to http://www.t10.org/new.htm (and http://www.t10.org/doc05.htm) to get rid of the out-of-date "non-zero" statement about portal group tags in SAM-4. It will be discussed in the September T10 CAP WG meeting. -- Rob Elliott, elliott@hp.com Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 18 21:40:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5vri-0001EX-EO; Thu, 18 Aug 2005 21:40:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5vrg-0001BS-NU for ips@megatron.ietf.org; Thu, 18 Aug 2005 21:40:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21760 for ; Thu, 18 Aug 2005 21:40:10 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5wRW-0007bx-1u for ips@ietf.org; Thu, 18 Aug 2005 22:17:16 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 4BB5F8706C; Thu, 18 Aug 2005 21:39:57 -0400 (EDT) In-Reply-To: <43051FBA.2020404@Sun.COM> References: <43025617.9040908@Sun.COM> <1124377696.5544.40.camel@localhost.localdomain> <43051FBA.2020404@Sun.COM> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <14d4ca8224863619352e23507fac2e3f@wasabisystems.com> From: William Studenmund Date: Thu, 18 Aug 2005 18:39:49 -0700 To: "Javen.Wu" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mingz@ele.uri.edu, ips@ietf.org Subject: [Ips] Re: Question about iSCSI reservation. 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="===============1238312131==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1238312131== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3-79501014" Content-Transfer-Encoding: 7bit --Apple-Mail-3-79501014 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 18, 2005, at 4:54 PM, Javen.Wu wrote: > William Studenmund wrote: > >> On Aug 18, 2005, at 8:08 AM, Ming Zhang wrote: >> >>> then how can u support those cluster service? >> >> >> RESERVE(6)/RELEASE(6) and Persistent reservations. > > As my understanding about Persistent reservation, We need use a unique > identification for each I-T nexus. My understanding is you need the same thing for the older reservation systems too. Note that according to SPC2, Reserve/Release reservations persist until released or the target is reset. Thus session reinstatement will not tear them down and you will have the same identification issues. > In iSCSI area, what identification was used for I-T nexus? > Session is I-T nexus in iSCSI concept. So SSID can identify iSCSI I-T > nexus. Not only can it, but that's what is SHOULD do. > SSID is composed by ISID and TSIH. However, I am wondering if the SSID > can identify I-T nexus for persistent reservation. Why would the SSID not be able to identify an I-T nexus for a persistent reservation? No, TSIH is not part of the SSID. The SSID is "(iSCSI Initiator Name + 'i' + ISID, iSCSI Target Name + 't' + Portal Group Tag)." While TPGT and ISID are in there, they are not all that's there. > I've read some software iSCSI initiator implementation. I think it is > possible for two host have same ISID. While they can have the same ISID, they should have separate InitiatorName values, so they will be separate I_T nexuses. > So I suspect iSCSI target have responsibility to make TSIH unique. > Otherwise, how to make sure which session is take the owner > persistently. No. There is no ambiguity here, and the target certainly shouldn't try to cook TSIH to differentiate different initiators. TSIH really is more of a versioning of a session as seen by the target. It is used to make sure that both the initiator and target are agreed as to what version of a session instance is currently operating. If the initiator tries to join a session (I_T nexus) but uses the wrong TSIH, the target knows either to reject the login attempt (attempt to join old/invalid session) or to trigger session reinstatement (initiator rebooted and is trying to login again). For TSIH to work like that, SSID needs to not change; if the SSID is different, we're talking about different I_T nexuses, so you can't compare TSIH values between them. Take care, Bill --Apple-Mail-3-79501014 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDBThsDJT2Egh26K0RAufsAJ9dTPaz6d3HiPuYWO3ll3+E1YtZhgCgkIxh JB3VYpUYiRTbZJGoClgyyXA= =6Bhu -----END PGP SIGNATURE----- --Apple-Mail-3-79501014-- --===============1238312131== 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 --===============1238312131==-- From ips-bounces@ietf.org Fri Aug 19 10:44:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E686L-0007LL-IK; Fri, 19 Aug 2005 10:44:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mTT-0003Kc-ND for ips@megatron.ietf.org; Thu, 18 Aug 2005 11:38:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13052 for ; Thu, 18 Aug 2005 11:38:33 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5n3C-0004k2-KZ for ips@ietf.org; Thu, 18 Aug 2005 12:15:34 -0400 Received: from dm-prc-02.singapore.sun.com ([129.158.71.110]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j7IFcTWR006069 for ; Thu, 18 Aug 2005 09:38:30 -0600 (MDT) Received: from sandieji.prc.sun.com (sandieji.PRC.Sun.COM [129.158.219.52]) by dm-prc-02.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL, v2.2) with ESMTP id j7IFdLIF004899 for ; Thu, 18 Aug 2005 23:39:22 +0800 (SGT) Received: from [127.0.0.1] (dhcp-ubrm05-50-127.Central.Sun.COM [129.147.50.127]) by sandieji.prc.sun.com (8.13.2+Sun/8.13.2) with ESMTP id j7IFcNgD009535; Thu, 18 Aug 2005 23:38:26 +0800 (CST) Message-ID: <4304AB66.6040003@Sun.COM> Date: Thu, 18 Aug 2005 23:38:14 +0800 From: "Javen.Wu" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mingz@ele.uri.edu Subject: Re: [Ips] Question about iSCSI 3rd party reservation. References: <43025617.9040908@Sun.COM> <1124377696.5544.40.camel@localhost.localdomain> In-Reply-To: <1124377696.5544.40.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Aug 2005 10:44:08 -0400 Cc: Tim Szeto , ips@ietf.org, William Studenmund X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Please refer to SPC3 revision 23 Annex B. Persistent reservation can replace RESERVE/RELEASE functionality. Ming Zhang wrote: >then how can u support those cluster service? > >ming > >On Wed, 2005-08-17 at 10:00 -0700, William Studenmund wrote: > > >>On Aug 16, 2005, at 2:09 PM, Javen.Wu wrote: >> >> >> >>>Hi guys, >>> >>> >>>>3d party reservation is mandatory implement in SPC3. >>>> >>>> >>As Bill noted, this statement is incorrect. >> >>What is correct is that, according to SPC2, if you implement the >>RESERVE(10) command, you also must implement 3rd party reservations. >> >> >> >>>>In fact, I want to know how the 3rd party reserve work for iSCSI. >>>>U know, if application wanna issue a 3rd party reservation. he will >>>>birng a 3rd party device ID in CDB. >>>>How to translate the 3rd party ID to a real node name? >>>> >>>> >>You don't. And that's the problem with RESERVE(10). >> >> >> >>>>I suspect if a parellel SCSI user wanna issue a 3rd reservation, he >>>>will fill Target ID to the 3rd device ID field. >>>>And if a FC user wanan issue a 3rd reservation, he will fill WWN to >>>>the 3rd device ID field. >>>>So I guess if a iSCSI user wanna issue 3rd reservation, the CDB of >>>>reserve(10) will bring iqn name. >>>> >>>> >>Technically the WWN is in the parameter list, which is transfered as >>part of the data phase. But you are correct that the command should >>carry the iqn name. And the problem with RESERVE(10) is that the >>parameter list can only be 8 bytes, which won't fit an iqn name. >> >>And that's why our (Wasabi's) target does not implement RESERVE(10) & >>RELEASE(10). It will never work right. >> >> >> >>>>I am not sure my guess is correct,just a guess. >>>>Your reponse is appreciated. I just wanna discuss SCSI protocol >>>>implementation in iSCSI target emulation. >>>>Thx again! >>>> >>>> >>_______________________________________________ >>Ips mailing list >>Ips@ietf.org >>https://www1.ietf.org/mailman/listinfo/ips >> >> > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Aug 19 10:44:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E686M-0007Lp-2O; Fri, 19 Aug 2005 10:44:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5uDq-0005AV-4o for ips@megatron.ietf.org; Thu, 18 Aug 2005 19:54:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17548 for ; Thu, 18 Aug 2005 19:54:56 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5unc-0004nw-QU for ips@ietf.org; Thu, 18 Aug 2005 20:32:00 -0400 Received: from dm-prc-01.singapore.sun.com ([129.158.71.109]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7INsqHT015605 for ; Thu, 18 Aug 2005 16:54:52 -0700 (PDT) Received: from sandieji.prc.sun.com (sandieji.PRC.Sun.COM [129.158.218.171]) by dm-prc-01.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL, v2.2) with ESMTP id j7INuDh9001633 for ; Fri, 19 Aug 2005 07:56:14 +0800 (SGT) Received: from [127.0.0.1] (dhcp-ubrm05-50-127.Central.Sun.COM [129.147.50.127]) by sandieji.prc.sun.com (8.13.2+Sun/8.13.2) with ESMTP id j7INshNq022107; Fri, 19 Aug 2005 07:54:48 +0800 (CST) Message-ID: <43051FBA.2020404@Sun.COM> Date: Fri, 19 Aug 2005 07:54:34 +0800 From: "Javen.Wu" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Studenmund References: <43025617.9040908@Sun.COM> <1124377696.5544.40.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Aug 2005 10:44:08 -0400 Cc: mingz@ele.uri.edu, ips@ietf.org Subject: [Ips] Question about iSCSI reservation. X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org William Studenmund wrote: > On Aug 18, 2005, at 8:08 AM, Ming Zhang wrote: > >> then how can u support those cluster service? > > > RESERVE(6)/RELEASE(6) and Persistent reservations. > > Take care, > > Bill As my understanding about Persistent reservation, We need use a unique identification for each I-T nexus. In iSCSI area, what identification was used for I-T nexus? Session is I-T nexus in iSCSI concept. So SSID can identify iSCSI I-T nexus. SSID is composed by ISID and TSIH. However, I am wondering if the SSID can identify I-T nexus for persistent reservation. I've read some software iSCSI initiator implementation. I think it is possible for two host have same ISID. So I suspect iSCSI target have responsibility to make TSIH unique. Otherwise, how to make sure which session is take the owner persistently. Best Regards Javen _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Aug 19 17:46:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Egy-0004yV-7I; Fri, 19 Aug 2005 17:46:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Egw-0004yN-H6 for ips@megatron.ietf.org; Fri, 19 Aug 2005 17:46:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07038 for ; Fri, 19 Aug 2005 17:46:19 -0400 (EDT) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6FGx-0001E8-H3 for ips@ietf.org; Fri, 19 Aug 2005 18:23:36 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc12) with SMTP id <2005081921461001400qae64e>; Fri, 19 Aug 2005 21:46:11 +0000 Message-ID: <000901c5a507$6e748010$03031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Fri, 19 Aug 2005 17:46:17 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.9 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ips] can't send but can receive ietf mail 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="===============0807606647==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0807606647== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C5A4E5.E68662C0" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C5A4E5.E68662C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a colleague that receives ietf reflector may but can't send. He = says he gets a bounce saying something like "a mail is being sent from = non-member to member only alias, it cannot be accepted" (may not be the = exact words). Can someone suggest what my colleague should do? Eddy ------=_NextPart_000_0006_01C5A4E5.E68662C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have a colleague that receives ietf reflector may = but can't=20 send. He says he gets a bounce saying something like "a = mail is=20 being sent from non-member to member only alias, it cannot be accepted" = (may not=20 be the exact words).
 
Can someone suggest what my colleague should=20 do?
 
Eddy
------=_NextPart_000_0006_01C5A4E5.E68662C0-- --===============0807606647== 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 --===============0807606647==-- From ips-bounces@ietf.org Fri Aug 19 17:49:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Ejw-0005HM-Fd; Fri, 19 Aug 2005 17:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Eju-0005HE-EZ for ips@megatron.ietf.org; Fri, 19 Aug 2005 17:49:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07137 for ; Fri, 19 Aug 2005 17:49:23 -0400 (EDT) Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6FJv-0001II-FI for ips@ietf.org; Fri, 19 Aug 2005 18:26:40 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc14) with SMTP id <2005081921491301400he97ce>; Fri, 19 Aug 2005 21:49:13 +0000 Message-ID: <001001c5a507$db5ff420$03031eac@ivivity.com> From: "Eddy Quicksall" To: Date: Fri, 19 Aug 2005 17:49:20 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Sanjay Goyal Subject: [Ips] DDP draft specification 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="===============0878829857==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0878829857== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C5A4E6.538EFBC0" This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5A4E6.538EFBC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm asking this question for a collegue that is having trouble sending = mail: Subject: DDP draft specification Hi, The below 2 sentences are from draft-ietf-rddp-ddp-05.txt 1. DDP provides enough information in each DDP Segment to allow the ULP = Payload in each inbound DDP Segment payloads to be directly Placed into = the correct ULP Buffer, even when the DDP Segments arrive out-of-order.=20 2. This specification requires reliable, in order Delivery LLPs. First sentence says that DDP segments which are MPA FPDUs in TCP case = can arrive out-of-order and second sentence says that LLP (MPA layer) = needs to provide ordered delivery. Isn't it contradictory? Regards, Sanjay ------=_NextPart_000_000D_01C5A4E6.538EFBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm asking this question for a collegue that is having trouble = sending=20 mail:

Subject: DDP draft specification

Hi,

The below 2 sentences are from draft-ietf-rddp-ddp-05.txt

1. DDP provides enough information in each DDP Segment to allow the = ULP=20 Payload in each inbound DDP Segment payloads to be directly Placed into = the=20 correct ULP Buffer, even when the DDP Segments arrive out-of-order.

2. This specification requires reliable, in order Delivery LLPs.

First sentence says that DDP segments which are MPA FPDUs in TCP case = can=20 arrive out-of-order and second sentence says that LLP (MPA layer) needs = to=20 provide ordered delivery. Isn't it contradictory?

Regards,

Sanjay

------=_NextPart_000_000D_01C5A4E6.538EFBC0-- --===============0878829857== 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 --===============0878829857==-- From ips-bounces@ietf.org Fri Aug 19 19:32:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6GLf-0006rS-MR; Fri, 19 Aug 2005 19:32:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6GLd-0006rD-I6 for ips@megatron.ietf.org; Fri, 19 Aug 2005 19:32:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12077 for ; Fri, 19 Aug 2005 19:32:25 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Gvf-0003pp-Fk for ips@ietf.org; Fri, 19 Aug 2005 20:09:44 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j7JNWFQW006378 for ; Fri, 19 Aug 2005 19:32:15 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7JNWFXY243328 for ; Fri, 19 Aug 2005 19:32:15 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j7JNW4jX021877 for ; Fri, 19 Aug 2005 19:32:04 -0400 Received: from [9.56.227.90] (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j7JNW4Tg021602; Fri, 19 Aug 2005 19:32:04 -0400 In-Reply-To: <001001c5a507$db5ff420$03031eac@ivivity.com> Importance: Normal MIME-Version: 1.0 To: "Eddy Quicksall" Subject: Re: [Ips] DDP draft specification X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Mike Ko Date: Fri, 19 Aug 2005 16:31:53 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_08072005|August 07, 2005) at 08/19/2005 19:32:04, Serialize complete at 08/19/2005 19:32:04 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ips@ietf.org, Sanjay Goyal X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Eddy, For a cleanly layered design, all LLP segments will be delivered in order. To provide out of order data placement support, the DDP draft stated in section 2.3 under "Direct Data Placement" that this "may require the Data Sink to implement the LLP and DDP as one functional block." Mike Sent by: ips-bounces@ietf.org To: cc: Sanjay Goyal Subject: [Ips] DDP draft specification I'm asking this question for a collegue that is having trouble sending mail: Subject: DDP draft specification Hi, The below 2 sentences are from draft-ietf-rddp-ddp-05.txt 1. DDP provides enough information in each DDP Segment to allow the ULP Payload in each inbound DDP Segment payloads to be directly Placed into the correct ULP Buffer, even when the DDP Segments arrive out-of-order. 2. This specification requires reliable, in order Delivery LLPs. First sentence says that DDP segments which are MPA FPDUs in TCP case can arrive out-of-order and second sentence says that LLP (MPA layer) needs to provide ordered delivery. Isn't it contradictory? Regards, Sanjay_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Aug 19 19:49:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Gc0-0001yv-J5; Fri, 19 Aug 2005 19:49:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Gbz-0001yp-A9 for ips@megatron.ietf.org; Fri, 19 Aug 2005 19:49:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12626 for ; Fri, 19 Aug 2005 19:49:19 -0400 (EDT) Received: from host52a.simplicato.com ([207.99.47.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6HC1-0004De-An for ips@ietf.org; Fri, 19 Aug 2005 20:26:38 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 83A7669A857; Fri, 19 Aug 2005 19:49:06 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94428-06; Fri, 19 Aug 2005 19:49:06 -0400 (EDT) Received: from [192.168.2.2] (dsl017-119-070.sfo1.dsl.speakeasy.net [69.17.119.70]) by host52a.simplicato.com (Postfix) with ESMTP id DB77D69A825; Fri, 19 Aug 2005 19:49:05 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21E24417-8450-4D47-A6F1-3D2D8331A4B6@asomi.com> Content-Transfer-Encoding: 7bit From: Caitlin Bestler Subject: Re: [Ips] DDP draft specification Date: Fri, 19 Aug 2005 16:41:13 -0700 To: Mike Ko X-Mailer: Apple Mail (2.734) X-Virus-Scanned: by amavisd-new at simplicato.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The DDP and LLP can still be cleanly layered with out of order placement, but the clean interface has to distinguish between when the LLP provides a DDP Segment for placement and when it is delivered. On Aug 19, 2005, at 4:31 PM, Mike Ko wrote: > Eddy, > > For a cleanly layered design, all LLP segments will be delivered in > order. > To provide out of order data placement support, the DDP draft > stated in > section 2.3 under "Direct Data Placement" that this "may require > the Data > Sink to implement the LLP and DDP as one functional block." > > Mike > Sent by: ips-bounces@ietf.org > To: > cc: Sanjay Goyal > Subject: [Ips] DDP draft specification > > > I'm asking this question for a collegue that is having trouble sending > mail: > Subject: DDP draft specification > Hi, > The below 2 sentences are from draft-ietf-rddp-ddp-05.txt > 1. DDP provides enough information in each DDP Segment to allow the > ULP > Payload in each inbound DDP Segment payloads to be directly Placed > into > the correct ULP Buffer, even when the DDP Segments arrive out-of- > order. > 2. This specification requires reliable, in order Delivery LLPs. > First sentence says that DDP segments which are MPA FPDUs in TCP > case can > arrive out-of-order and second sentence says that LLP (MPA layer) > needs to > provide ordered delivery. Isn't it contradictory? > Regards, > Sanjay_______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Aug 20 14:46:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6YMR-0000Dp-Tq; Sat, 20 Aug 2005 14:46:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6YMQ-0000Dk-QA for ips@megatron.ietf.org; Sat, 20 Aug 2005 14:46:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03034 for ; Sat, 20 Aug 2005 14:46:29 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Ywd-00035b-U4 for ips@ietf.org; Sat, 20 Aug 2005 15:23:56 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j7KIkQUb013685; Sat, 20 Aug 2005 14:46:26 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 20 Aug 2005 14:46:26 -0400 Message-ID: To: eddy_quicksall_iVivity_iSCSI@comcast.net, ips@ietf.org Subject: RE: [Ips] can't send but can receive ietf mail Date: Sat, 20 Aug 2005 14:46:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.8.20.20 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.5 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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="===============0248260070==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0248260070== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A5B7.1308E722" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5A5B7.1308E722 Content-Type: text/plain Eddy, He should subscribe to the mailing list using the email address he actually sends email from (what is actually in the From: line of his emails). The "bounces" are not rejections - if he reads them carefully, he'll discover that his emails are being held until the list moderator (yours truly) can examine and approve them. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _____ From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Eddy Quicksall Sent: Friday, August 19, 2005 5:46 PM To: ips@ietf.org Subject: [Ips] can't send but can receive ietf mail I have a colleague that receives ietf reflector may but can't send. He says he gets a bounce saying something like "a mail is being sent from non-member to member only alias, it cannot be accepted" (may not be the exact words). Can someone suggest what my colleague should do? Eddy ------_=_NextPart_001_01C5A5B7.1308E722 Content-Type: text/html
Eddy,
 
He should subscribe to the mailing list using the email address he actually
sends email from (what is actually in the From: line of his emails).  The
"bounces" are not rejections - if he reads them carefully, he'll discover
that his emails are being held until the list moderator (yours truly) can
examine and approve them.
 
Thanks,
--David

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

From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Eddy Quicksall
Sent: Friday, August 19, 2005 5:46 PM
To: ips@ietf.org
Subject: [Ips] can't send but can receive ietf mail

I have a colleague that receives ietf reflector may but can't send. He says he gets a bounce saying something like "a mail is being sent from non-member to member only alias, it cannot be accepted" (may not be the exact words).
 
Can someone suggest what my colleague should do?
 
Eddy
------_=_NextPart_001_01C5A5B7.1308E722-- --===============0248260070== 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 --===============0248260070==-- From ips-bounces@ietf.org Sat Aug 20 15:00:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6YaQ-0002F0-9U; Sat, 20 Aug 2005 15:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6YaO-0002Ek-UV for ips@megatron.ietf.org; Sat, 20 Aug 2005 15:00:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03374 for ; Sat, 20 Aug 2005 15:00:55 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6ZAb-0003M4-6A for ips@ietf.org; Sat, 20 Aug 2005 15:38:22 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j7KJ0pk7022441 for ; Sat, 20 Aug 2005 15:00:51 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 20 Aug 2005 15:00:51 -0400 Message-ID: To: ips@ietf.org Date: Sat, 20 Aug 2005 15:00:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.8.20.22 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [Ips] iSER over IB - Consensus call result X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Having seen no objection to this approach (see forwarded message below), this is what we're going to do with one small change - Based on recent list discussion, it is apparent that some changes beyond what is in draft-hufferd-iser-ib-00.txt are needed and/or desired for the iSER draft. A -01 version of the hufferd draft will be issued along with an explanation of what was and was not picked up from list discussion, and why, along with a new marked-up PDF version of the iSER -05 candidate draft showing what the changes will look like. A WG Last Call will be conducted on the -01 version of draft-hufferd-iser-ib with all changes (even editorial) to be sent to the list. The editor of the iSER draft is also doing some minor editorial cleanups on the iSER draft that should have no technical or semantic impact - these will be visible in the version of the candidate draft when the WG Last Call is issued on draft-hufferd-iser-ib-01.txt. Thanks, --David (ips WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Black, David > Sent: Tuesday, August 09, 2005 11:02 PM > To: ips@ietf.org > Subject: [Ips] iSER over IB - Consensus call > > The IPS WG Paris meeting discussed: > > iSER over InfiniBand (draft-hufferd-iser-ib-00.txt) > > Proposal for text edits to iSER to permit use on other transports, > including InfiniBand. Also will help enable iSER to be defined over > SCTP. > > This draft is (or at least is intended to be) entirely editorial - > it does not (or at least is not intended to) make any technical > changes to the iSER draft that has passed WG Last Call. > > The draft Paris minutes record the following: > > Sense of room: Want to proceed towards applying these changes > (after careful review and WG rough consensus) to the approved > iSER draft so that there is one draft that is broadly applicable > rather than the current iSER draft plus a draft that modifies > that draft to broaden it. > > Anyone who objects to this sense of the room in Paris should post > to the list with reasons for the objection, otherwise the sense of > the room to proceed in this direction will become the rough consensus > of the IPS WG. > > If the WG does proceed in this direction, the next step will be a WG > Last Call on draft-hufferd-iser-ib-00.txt, with all changes/comments/etc. > to be posted to the list, even editorial ones. After conclusion of > that WG Last Call, the resulting edits can be applied to produce a new > version of the iSER draft. We'll try to get this done by the end > of August, but it may take a bit longer. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sat Aug 20 15:02:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Ybg-0002Ow-0Q; Sat, 20 Aug 2005 15:02:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Ybe-0002O3-Aj for ips@megatron.ietf.org; Sat, 20 Aug 2005 15:02:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03426 for ; Sat, 20 Aug 2005 15:02:13 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6ZBr-0003OZ-J4 for ips@ietf.org; Sat, 20 Aug 2005 15:39:39 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j7KJ2B3V011162 for ; Sat, 20 Aug 2005 15:02:11 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 20 Aug 2005 15:02:11 -0400 Message-ID: To: ips@ietf.org Date: Sat, 20 Aug 2005 15:02:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.8.20.22 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [Ips] IPS Paris minutes X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Having seen no changes on the list, these are now the FINAL ips WG Paris minutes. Thanks, --David The IP Storage (ips) WG meets 1815-1945 on Tuesday, August 2, 2005 at the IETF meetings in Paris, France. AGENDA ------ Administrivia, agenda bashing, draft status review, etc.: 15 min David L. Black, EMC (co-chair) Blue sheets Note Well WG chair change - Elizabeth Rodriguez has resigned as co-chair. David Black will continue as the sole chair. Milestones (charter milestones need revision) Draft status - iSER and DA are through WG Last Call. Publication will be requested by end of August. MIB Status (I-D tracker is not up to date): - MIBs requiring expert re-review: SCSI, iFCP, iSCSI - Expert review comments received and waiting for new version: FCIP, iSCSI Authorization - New version of MIB recently submitted, needs expert review: iSNS iFCP draft is in RFC Editor's queue, among others. iFCP appears to be waiting on authors to respond to RFC Editor question on references. iSCSI Implementer's Guide (draft-ietf-ips-iscsi-impl-guide-00.txt): 15 min David L. Black, EMC (co-chair) for Mallikarjun Chadalapaka, HP (editor) FYI and opportunity for comments. The draft will remain open well into 2006, and the mailing list is the primary forum for working on it. iSER over InfiniBand: up to 1 hour John Hufferd, Brocade draft-hufferd-iser-ib-00.txt Proposal for text edits to iSER to permit use on other transports, including InfiniBand. Also will help enable iSER to be defined over SCTP. See John's slides. Important meeting notes: SHOULD implement IPsec-equivalent security for non-IP transports appears to be the right approach (no objection in room - WG chair is ok with this). iSER discovery on IB will rely upon (and require presence of) IP over IB. Sense of room: Want to proceed towards applying these changes (after careful review and WG rough consensus) to the approved iSER draft so that there is one draft that is broadly applicable rather than the current iSER draft plus a draft that modifies that draft to broaden it. iSCSI Discovery Data Extensions: Conceptual Discussion John Hufferd, Brocade Extending iSCSI discovery to support other transports. Meeting discussion: Not sure until all the details are worked out, starting with backwards compatibility and protocol gateways of varying transparency. Overall approach is worthy of further investigation. ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 22 11:13:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DzV-0003LB-AH; Mon, 22 Aug 2005 11:13:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DzS-0003L6-GP for ips@megatron.ietf.org; Mon, 22 Aug 2005 11:13:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21811 for ; Mon, 22 Aug 2005 11:13:32 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Ea2-0003vi-O6 for ips@ietf.org; Mon, 22 Aug 2005 11:51:23 -0400 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7MFATs28280; Mon, 22 Aug 2005 11:10:29 -0400 (EDT) Received: from TRAVOS-2K.nortel.com (travos-2k.us.nortel.com [47.16.54.211]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RCFPMXGM; Mon, 22 Aug 2005 11:12:20 -0400 Message-Id: <6.2.3.4.2.20050822105446.03845fd0@zbl6c002.corpeast.baynetworks.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 22 Aug 2005 11:11:31 -0400 To: Black_David@emc.com, ips@ietf.org From: "Franco Travostino" Subject: Re: [Ips] IPS Paris minutes In-Reply-To: References: Mime-Version: 1.0 X-Spam-Score: 1.7 (+) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c 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="===============1276266465==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1276266465== Content-Type: multipart/alternative; boundary="=====================_9247987==.ALT" --=====================_9247987==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:02 PM 8/20/2005, Black_David@emc.com wrote: > iFCP draft is in RFC Editor's queue, among others. iFCP appears > to be waiting on authors to respond to RFC Editor question on > references. Hi, David, we thought we had addressed the RFC Editor's issues on references (see hereafter). We haven't heard from the RFC Editor ever since. Do you have evidence of further issues? -franco >From: Charles Monia >To: rfc-editor@rfc-editor.org >Cc: Charles Monia , > "Travostino, Franco [BL60:470:EXCH]" , > wayland@troikanetworks.com, Elizabeth.Rodriguez@DotHill.com, > black_david@emc.com, medwards@eurologic.com >Subject: draft-ietf-ips-ifcp-14.txt suggested editorial changes >Date: Mon, 9 May 2005 16:31:23 -0400 >X-Mailer: Normal >X-SMTP-HELO: Normal >X-SMTP-MAIL-FROM: Normal >X-SMTP-RCPT-TO: Normal >X-SMTP-PEER-INFO: Normal > >Hi Folks: > >The following addresses the discrepancies found by the RFC editor. > >RFC Editorial comment 1: > > The following have been textually cited, but not referenced: > > [FC-VI] > > [FCS] >Suggested editorial action:: > >1. Add the following to section 14, Non-normative References: > >[FC-VI] ANSI/INCITS 357:2002, "Fibre Channel Virtual Interface >Architecture Mapping Protocol (FC-VI)", NCITS Project 1332-D, July 2000. > >2. Change all occurrences of the erroneous [FCS] reference >throughout the document to [FC-FS]. (To my knowledge, the only such >reference occurs in the RES ACC response frame on on pp 70. >Comment 2: > > The following references do not have textual citations: > > [RFC1305] Mills, D., "Network Time Protocol (Version 3) > Specification, Implementation", RFC 1305, March 1992. > > [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC > 2131, March 1997. > > [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, > September 1981. >Suggested editorial action: > >The specified references should be deleted. > >Other editorial changes: > >The email address for the Rod Mullendor/Charles Monia entry in the >author's addresses of section 13 should be changed >to Rod.Mullendore@MCDATA.com. > > > Regards, >Charles Monia >-----Original Message----- >From: Franco Travostino [mailto:travos@nortel.com] >Sent: Tuesday, April 26, 2005 6:44 PM >To: 'rfc-editor@rfc-editor.org'; 'wayland@troikanetworks.com'; >'medwards@eurologic.com'; 'cmonia@pacbell.net' >Cc: 'Elizabeth.Rodriguez@DotHill.com'; 'black_david@emc.com' >Subject: Re: draft-ietf-ips-ifcp-14.txt > > >I will be working with the authors and get back to you as soon as possible. > >Thanks >-franco > >-------------------------- >Sent from my BlackBerry Wireless Handheld > >-----Original Message----- >From: RFC Editor >To: cmonia@nishansystems.com ; >travos@nortelnetworks.com ; >wayland@troikanetworks.com ; >medwards@eurologic.com > >CC: RFC Editor ; Allison Mankin >; Jon Peterson ; >Elizabeth.Rodriguez@DotHill.com ; >black_david@emc.com > >Sent: Tue Apr 26 19:03:45 2005 >Subject: draft-ietf-ips-ifcp-14.txt > >Authors, > >While editing this document, we have come across the following >reference/citation discrepancies: > > The following have been textually cited, but not referenced: > > [FC-VI] > > [FCS] > > Please provide us with the reference information for these > documents. > > > The following references do not have textual citations: > > [RFC1305] Mills, D., "Network Time Protocol (Version 3) > Specification, Implementation", RFC 1305, March 1992. > > [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC > 2131, March 1997. > > [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, > September 1981. > > Please let us know where these references should be cited in the > text. If they are not to be cited, they will be deleted. > >Please let us know if you have any updated contact information for Rod >Mullendore, as there was no email address provided. > >Your document will not move forward in the publication process until >these issues have been resolved. > >Thank you. > >RFC Editor --=====================_9247987==.ALT Content-Type: text/html; charset="us-ascii" At 03:02 PM 8/20/2005, Black_David@emc.com wrote:
        iFCP draft is in RFC Editor's queue, among others.  iFCP appears
        to be waiting on authors to respond to RFC Editor question on
        references.

Hi, David,
we thought we had addressed the RFC Editor's issues on references (see hereafter). We haven't heard from the RFC Editor ever since. Do you have evidence of further issues?

-franco

From: Charles Monia <cmonia@pacbell.net>
To: rfc-editor@rfc-editor.org
Cc: Charles Monia <cmonia@pacbell.net>,
         "Travostino, Franco [BL60:470:EXCH]" <TRAVOS@AmericasM06.nt.com>,
         wayland@troikanetworks.com, Elizabeth.Rodriguez@DotHill.com,
         black_david@emc.com, medwards@eurologic.com
Subject: draft-ietf-ips-ifcp-14.txt  suggested editorial changes
Date: Mon, 9 May 2005 16:31:23 -0400
X-Mailer: Normal
X-SMTP-HELO: Normal
X-SMTP-MAIL-FROM: Normal
X-SMTP-RCPT-TO: Normal
X-SMTP-PEER-INFO: Normal

Hi Folks:
 
The following addresses the discrepancies found by the RFC editor.
 
RFC Editorial comment 1:

   The following have been textually cited, but not referenced:

      [FC-VI]

      [FCS]
Suggested editorial action::
 
1. Add the following to section 14, Non-normative References:
 
[FC-VI] ANSI/INCITS 357:2002, "Fibre Channel Virtual Interface Architecture Mapping Protocol (FC-VI)", NCITS Project 1332-D, July 2000.

2. Change all occurrences of the erroneous [FCS] reference throughout the document to [FC-FS]. (To my knowledge, the only such reference occurs in the RES ACC response frame on on pp 70.
Comment 2:
 
   The following references do not have textual citations:

      [RFC1305] Mills, D., "Network Time Protocol (Version 3)
      Specification, Implementation", RFC 1305, March 1992.

      [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
      2131, March 1997.

      [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
      September 1981.
Suggested editorial action:
 
The specified references should be deleted.
 
Other editorial changes:
 
The email address for the Rod Mullendor/Charles Monia entry in the author's  addresses of section 13   should be changed to  Rod.Mullendore@MCDATA.com .
 
 
  Regards,
Charles Monia
-----Original Message-----
From: Franco Travostino [ mailto:travos@nortel.com]
Sent: Tuesday, April 26, 2005 6:44 PM
To: 'rfc-editor@rfc-editor.org'; 'wayland@troikanetworks.com'; 'medwards@eurologic.com'; 'cmonia@pacbell.net'
Cc: 'Elizabeth.Rodriguez@DotHill.com'; 'black_david@emc.com'
Subject: Re: draft-ietf-ips-ifcp-14.txt


I will be working with the authors and get back to you as soon as possible.

Thanks
-franco

--------------------------
Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: RFC Editor <rfc-editor@rfc-editor.org>
To: cmonia@nishansystems.com <cmonia@nishansystems.com>; travos@nortelnetworks.com <travos@nortelnetworks.com>; wayland@troikanetworks.com <wayland@troikanetworks.com>; medwards@eurologic.com <medwards@eurologic.com>

CC: RFC Editor <rfc-editor@rfc-editor.org>; Allison Mankin <mankin@psg.com>; Jon Peterson <jon.peterson@neustar.biz>; Elizabeth.Rodriguez@DotHill.com <Elizabeth.Rodriguez@DotHill.com>; black_david@emc.com <black_david@emc.com>

Sent: Tue Apr 26 19:03:45 2005
Subject: draft-ietf-ips-ifcp-14.txt

Authors,

While editing this document, we have come across the following
reference/citation discrepancies:

   The following have been textually cited, but not referenced:

      [FC-VI]

      [FCS]

   Please provide us with the reference information for these
   documents.

  
   The following references do not have textual citations:

      [RFC1305] Mills, D., "Network Time Protocol (Version 3)
      Specification, Implementation", RFC 1305, March 1992.

      [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
      2131, March 1997.

      [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
      September 1981.

   Please let us know where these references should be cited in the
   text.  If they are not to be cited, they will be deleted. 

Please let us know if you have any updated contact information for Rod
Mullendore, as there was no email address provided.

Your document will not move forward in the publication process until
these issues have been resolved.

Thank you.

RFC Editor


--=====================_9247987==.ALT-- --===============1276266465== 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 --===============1276266465==-- From ips-bounces@ietf.org Mon Aug 22 19:54:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7M7U-0001WS-Am; Mon, 22 Aug 2005 19:54:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7M7S-0001WN-PV for ips@megatron.ietf.org; Mon, 22 Aug 2005 19:54:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05438 for ; Mon, 22 Aug 2005 19:54:19 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7M7S-0007og-So for ips@ietf.org; Mon, 22 Aug 2005 19:54:23 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j7MNsBVw026193; Mon, 22 Aug 2005 19:54:11 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Aug 2005 19:54:11 -0400 Message-ID: To: travos@nortel.com, ips@ietf.org Subject: RE: [Ips] IPS Paris minutes Date: Mon, 22 Aug 2005 19:54:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.8.22.32 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HTML_FONT_BLUE 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 2.0 (++) X-Scan-Signature: e06437eb72f6703f11713d345be8298a 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="===============1618264935==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1618264935== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A774.B316A1C1" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5A774.B316A1C1 Content-Type: text/plain Franco, That "appears" was wrong - there is no outstanding issue, and the RFC Editor has been asked to expedite publication of iFCP, iSNS, and related drafts. Thanks, --David p.s. No I have to go fix the submitted minutes ... ---------------------------------------------------- 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 ---------------------------------------------------- _____ From: Franco Travostino [mailto:travos@nortel.com] Sent: Monday, August 22, 2005 11:12 AM To: Black, David; ips@ietf.org Subject: Re: [Ips] IPS Paris minutes At 03:02 PM 8/20/2005, Black_David@emc.com wrote: iFCP draft is in RFC Editor's queue, among others. iFCP appears to be waiting on authors to respond to RFC Editor question on references. Hi, David, we thought we had addressed the RFC Editor's issues on references (see hereafter). We haven't heard from the RFC Editor ever since. Do you have evidence of further issues? -franco From: Charles Monia To: rfc-editor@rfc-editor.org Cc: Charles Monia , "Travostino, Franco [BL60:470:EXCH]" , wayland@troikanetworks.com, Elizabeth.Rodriguez@DotHill.com, black_david@emc.com, medwards@eurologic.com Subject: draft-ietf-ips-ifcp-14.txt suggested editorial changes Date: Mon, 9 May 2005 16:31:23 -0400 X-Mailer: Normal X-SMTP-HELO: Normal X-SMTP-MAIL-FROM: Normal X-SMTP-RCPT-TO: Normal X-SMTP-PEER-INFO: Normal Hi Folks: The following addresses the discrepancies found by the RFC editor. RFC Editorial comment 1: The following have been textually cited, but not referenced: [FC-VI] [FCS] Suggested editorial action:: 1. Add the following to section 14, Non-normative References: [FC-VI] ANSI/INCITS 357:2002, "Fibre Channel Virtual Interface Architecture Mapping Protocol (FC-VI)", NCITS Project 1332-D, July 2000. 2. Change all occurrences of the erroneous [FCS] reference throughout the document to [FC-FS]. (To my knowledge, the only such reference occurs in the RES ACC response frame on on pp 70. Comment 2: The following references do not have textual citations: [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. Suggested editorial action: The specified references should be deleted. Other editorial changes: The email address for the Rod Mullendor/Charles Monia entry in the author's addresses of section 13 should be changed to Rod.Mullendore@MCDATA.com . Regards, Charles Monia -----Original Message----- From: Franco Travostino [ mailto:travos@nortel.com] Sent: Tuesday, April 26, 2005 6:44 PM To: 'rfc-editor@rfc-editor.org'; 'wayland@troikanetworks.com'; 'medwards@eurologic.com'; 'cmonia@pacbell.net' Cc: 'Elizabeth.Rodriguez@DotHill.com'; 'black_david@emc.com' Subject: Re: draft-ietf-ips-ifcp-14.txt I will be working with the authors and get back to you as soon as possible. Thanks -franco -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: RFC Editor To: cmonia@nishansystems.com ; travos@nortelnetworks.com ; wayland@troikanetworks.com ; medwards@eurologic.com CC: RFC Editor ; Allison Mankin ; Jon Peterson ; Elizabeth.Rodriguez@DotHill.com ; black_david@emc.com Sent: Tue Apr 26 19:03:45 2005 Subject: draft-ietf-ips-ifcp-14.txt Authors, While editing this document, we have come across the following reference/citation discrepancies: The following have been textually cited, but not referenced: [FC-VI] [FCS] Please provide us with the reference information for these documents. The following references do not have textual citations: [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. Please let us know where these references should be cited in the text. If they are not to be cited, they will be deleted. Please let us know if you have any updated contact information for Rod Mullendore, as there was no email address provided. Your document will not move forward in the publication process until these issues have been resolved. Thank you. RFC Editor ------_=_NextPart_001_01C5A774.B316A1C1 Content-Type: text/html
Franco,
 
That "appears" was wrong - there is no outstanding issue,
and the RFC Editor has been asked to expedite publication
of iFCP, iSNS, and related drafts.
 
Thanks,
--David
p.s.  No I have to go fix the submitted minutes ...
----------------------------------------------------
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
----------------------------------------------------

From: Franco Travostino [mailto:travos@nortel.com]
Sent: Monday, August 22, 2005 11:12 AM
To: Black, David; ips@ietf.org
Subject: Re: [Ips] IPS Paris minutes

At 03:02 PM 8/20/2005, Black_David@emc.com wrote:
        iFCP draft is in RFC Editor's queue, among others.  iFCP appears
        to be waiting on authors to respond to RFC Editor question on
        references.

Hi, David,
we thought we had addressed the RFC Editor's issues on references (see hereafter). We haven't heard from the RFC Editor ever since. Do you have evidence of further issues?

-franco

From: Charles Monia <cmonia@pacbell.net>
To: rfc-editor@rfc-editor.org
Cc: Charles Monia <cmonia@pacbell.net>,
         "Travostino, Franco [BL60:470:EXCH]" <TRAVOS@AmericasM06.nt.com>,
         wayland@troikanetworks.com, Elizabeth.Rodriguez@DotHill.com,
         black_david@emc.com, medwards@eurologic.com
Subject: draft-ietf-ips-ifcp-14.txt  suggested editorial changes
Date: Mon, 9 May 2005 16:31:23 -0400
X-Mailer: Normal
X-SMTP-HELO: Normal
X-SMTP-MAIL-FROM: Normal
X-SMTP-RCPT-TO: Normal
X-SMTP-PEER-INFO: Normal

Hi Folks:
 
The following addresses the discrepancies found by the RFC editor.
 
RFC Editorial comment 1:

   The following have been textually cited, but not referenced:

      [FC-VI]

      [FCS]
Suggested editorial action::
 
1. Add the following to section 14, Non-normative References:
 
[FC-VI] ANSI/INCITS 357:2002, "Fibre Channel Virtual Interface Architecture Mapping Protocol (FC-VI)", NCITS Project 1332-D, July 2000.

2. Change all occurrences of the erroneous [FCS] reference throughout the document to [FC-FS]. (To my knowledge, the only such reference occurs in the RES ACC response frame on on pp 70.
Comment 2:
 
   The following references do not have textual citations:

      [RFC1305] Mills, D., "Network Time Protocol (Version 3)
      Specification, Implementation", RFC 1305, March 1992.

      [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
      2131, March 1997.

      [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
      September 1981.
Suggested editorial action:
 
The specified references should be deleted.
 
Other editorial changes:
 
The email address for the Rod Mullendor/Charles Monia entry in the author's  addresses of section 13   should be changed to  Rod.Mullendore@MCDATA.com .
 
 
 Regards,
Charles Monia
-----Original Message-----
From: Franco Travostino [ mailto:travos@nortel.com]
Sent: Tuesday, April 26, 2005 6:44 PM
To: 'rfc-editor@rfc-editor.org'; 'wayland@troikanetworks.com'; 'medwards@eurologic.com'; 'cmonia@pacbell.net'
Cc: 'Elizabeth.Rodriguez@DotHill.com'; 'black_david@emc.com'
Subject: Re: draft-ietf-ips-ifcp-14.txt


I will be working with the authors and get back to you as soon as possible.

Thanks
-franco

--------------------------
Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: RFC Editor <rfc-editor@rfc-editor.org>
To: cmonia@nishansystems.com <cmonia@nishansystems.com>; travos@nortelnetworks.com <travos@nortelnetworks.com>; wayland@troikanetworks.com <wayland@troikanetworks.com>; medwards@eurologic.com <medwards@eurologic.com>

CC: RFC Editor <rfc-editor@rfc-editor.org>; Allison Mankin <mankin@psg.com>; Jon Peterson <jon.peterson@neustar.biz>; Elizabeth.Rodriguez@DotHill.com <Elizabeth.Rodriguez@DotHill.com>; black_david@emc.com <black_david@emc.com>

Sent: Tue Apr 26 19:03:45 2005
Subject: draft-ietf-ips-ifcp-14.txt

Authors,

While editing this document, we have come across the following
reference/citation discrepancies:

   The following have been textually cited, but not referenced:

      [FC-VI]

      [FCS]

   Please provide us with the reference information for these
   documents.

  
   The following references do not have textual citations:

      [RFC1305] Mills, D., "Network Time Protocol (Version 3)
      Specification, Implementation", RFC 1305, March 1992.

      [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
      2131, March 1997.

      [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
      September 1981.

   Please let us know where these references should be cited in the
   text.  If they are not to be cited, they will be deleted. 

Please let us know if you have any updated contact information for Rod
Mullendore, as there was no email address provided.

Your document will not move forward in the publication process until
these issues have been resolved.

Thank you.

RFC Editor


------_=_NextPart_001_01C5A774.B316A1C1-- --===============1618264935== 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 --===============1618264935==-- From ips-bounces@ietf.org Tue Aug 23 16:53:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7fm7-0008D6-HY; Tue, 23 Aug 2005 16:53:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7fm4-0008AO-MV for ips@megatron.ietf.org; Tue, 23 Aug 2005 16:53:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11030 for ; Tue, 23 Aug 2005 16:53:32 -0400 (EDT) Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7fmB-0005ar-HK for ips@ietf.org; Tue, 23 Aug 2005 16:53:46 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel6.hp.com (Postfix) with ESMTP id D70C67549 for ; Tue, 23 Aug 2005 16:52:54 -0400 (EDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.40]) by rosemail.rose.hp.com (Postfix) with ESMTP id 80111822E for ; Tue, 23 Aug 2005 13:51:00 -0700 (PDT) Message-ID: <430B8C9F.9000202@rose.hp.com> Date: Tue, 23 Aug 2005 13:52:47 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] Login Phase in iSER over IB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I can understand the desire to permit iSCSI Login on IB RCs. I can also see why a message delivery-capable transport (say, MDT for short) naturally aligns with iSCSI Login needs. However, note that iSER draft itself does not specify "iSCSI login on MDT" for good reasons. iSER draft assumes that iSCSI login phase mechanics are defined elsewhere, and so simply imposes certain key negotiation semantics on a known mechanism (and of course defines the FFP behavior). Having said that, I readily agree that the iSER draft should not disallow such an eventuality. I do not however think that iSER draft should explicitly sanction a new iSCSI/MDT login mechanism now unless it can reference at least one standard that defines such a login mechanism. My concern with such a reference would be the normative dependency and the potential delay. My apologies if these details were already discussed in the Paris meeting, I missed it. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Alex Nezhinsky wrote: > > > I would like to propose some changes for the "iSER over IB" draft > (http://www.ietf.org/internet-drafts/draft-hufferd-iser-ib-00.txt). The > changes being proposed address a group of statements regarding possible > mechanisms of message exchange during the iSER Login Phase in protocols > such as IB. > > The following statement is an example (section 3.1.6): "For LLPs that > have message delivery capability such as [IB], the iSCSI Layer *may* use > that messaging capability immediately after connection establishment > before enabling iSER-assisted mode." > > Because IB as such does not provide streaming capability equivalent to > the plain (not RDMA-enabled) TCP mode in iWARP, a substitute for it > should be found elsewhere. One option is to use the messaging > capabilities provided by the transport layer itself. This is a valid > option because the Login phase exchange is carried out in half-duplex > mode. It can be understood from the previous statement that using two > separate connections for the iSCSI Login and iSER Full-Feature phases > is also allowed. For example, the Login phase is carried out using an > IPoIB connection, while the iSER part is carried out using a separate IB > RC connection. > > In order to clarify that only using a single transport connection is > mandated, the following changes are proposed: > > 1) In 3.1.6 the third paragraph is to be replaced with: > > *"And in that same section (4.1) the next to last * paragraph is hereby > replaced with the following: * > > * * For a transport layer that operates in stream mode such as TCP, > the RDMA-Capable Protocol implementation supports the enabling of the > RDMA mode after Connection establishment and the exchange of Login > parameters in stream mode. For a transport layer that provides message > delivery capability, such as [IB], the RDMA-Capable Protocol > implementation supports the use of this messaging capability by the > iSCSI Layer directly for the Login phase after connection establishment > before enabling iSER-assisted mode." * > > 2) In 3.1.6.1 the first paragraph is to be repaced with: > > *"For a transport layer that provides message delivery capability, such > as [IB], the iSCSI Layer MUST interact with the transport layer directly > to use the messaging capability for exchanging the iSCSI Login Request > and Login Response PDUs. The method for establishing the actual > connection is protocol specific and outside the scope of this > specification. The same connection MUST be used for both the iSCSI Login > phase and the subsequent iSER-supported Full-Feature phase.* > > Alexander Nezhinsky > > Software Engineer > Infiniband Storage Solutions > www.voltaire.com > 9 Ha-Menofim, Herzelya 46725 Israel > tel: +972- 9- 9717637 > fax: +972- 9- 9717660 > mobile: +972-50-7504376 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 24 07:00:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7szw-0000t5-JD; Wed, 24 Aug 2005 07:00:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7szs-0000t0-PB for ips@megatron.ietf.org; Wed, 24 Aug 2005 07:00:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12768 for ; Wed, 24 Aug 2005 07:00:41 -0400 (EDT) Received: from volter-fw.ser.netvision.net.il ([212.143.107.30] helo=taurus.voltaire.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7t0A-0003fT-4p for ips@ietf.org; Wed, 24 Aug 2005 07:01:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ips] Login Phase in iSER over IB Date: Wed, 24 Aug 2005 14:00:13 +0300 Message-ID: Thread-Topic: Re: [Ips] Login Phase in iSER over IB Thread-Index: AcWomwCz3qfUCY2QR8+5Oj3M135NKw== From: "Alex Nezhinsky" To: "Mallikarjun C." X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun C. wrote: > I do not however think that iSER draft should explicitly sanction a new iSCSI/MDT > login mechanism now unless it can reference at least one standard that defines such=20 > a login mechanism. My concern with such a reference would be the normative=20 > dependency and the potential delay. Mallikarjun, The only explicit sanctioning here is the requirement to use the same connection on the=20 transport level both for the login and the full-featured phases:=20 > The same connection MUST be used for both the iSCSI Login phase and the subsequent > iSER-supported Full-Feature phase This may be achieved in many ways, and the only thing which was intended to be avoided was =20 opening one stream-based connection (like IPoIB) for the Login phase and then going on with=20 a (different) MDT-based connection (like IB RC) for the Full-Feature phase.=20 Such option was proposed by many readers or potential implementers (the last post=20 with such proposal that I read has been issued today) as an intuitive reaction to the lack of=20 stream support in IB RC.=20 I believe that you do not have to reference a standard that explicitely defines a new login=20 mechanism, only warn that any such mechanism has to use a single transport connection. Alexander Nezhinsky Software Engineer Infiniband Storage Solutions http://www.voltaire.com/ 9 Ha-Menofim, Herzelya 46725 Israel tel: +972- 9- 9717637 fax: +972- 9- 9717660 mobile: +972-50-7504376 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 24 09:59:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7vn4-0003JM-NY; Wed, 24 Aug 2005 09:59:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7vn3-0003JA-4J for ips@megatron.ietf.org; Wed, 24 Aug 2005 09:59:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21717 for ; Wed, 24 Aug 2005 09:59:39 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7vnM-00016j-O2 for ips@ietf.org; Wed, 24 Aug 2005 10:00:01 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j7ODxbef007574 for ; Wed, 24 Aug 2005 09:59:37 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Aug 2005 09:59:36 -0400 Message-ID: To: ips@ietf.org Date: Wed, 24 Aug 2005 09:59:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.8.24.12 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ips] Mailing list cleanup X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org In order to try to clean up the IPS mailing list, I've just re-enabled email delivery to a several dozen email addresses that were disabled for unknown reasons. Most of these are dead addresses that were generating bounces prior to an IETF email software upgrade a year or so ago - these addresses will again generate bounces and be automatically removed from the list by the current email software. OTOH, there may be some addresses where the list member deliberately disabled email delivery - if you're one of these people and are getting this email message unexpectedly, send me a note and I'll re-disable email delivery to you. Sorry for the intrusion, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 24 16:04:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81UD-0003ii-5I; Wed, 24 Aug 2005 16:04:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81UA-0003dd-6g for ips@megatron.ietf.org; Wed, 24 Aug 2005 16:04:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17222 for ; Wed, 24 Aug 2005 16:04:30 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81UT-00064a-Js for ips@ietf.org; Wed, 24 Aug 2005 16:04:56 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel12.hp.com (Postfix) with ESMTP id 324D9403B8F for ; Wed, 24 Aug 2005 13:04:23 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.40]) by rosemail.rose.hp.com (Postfix) with ESMTP id 5A67C825A for ; Wed, 24 Aug 2005 13:02:25 -0700 (PDT) Message-ID: <430CD2C6.4050506@rose.hp.com> Date: Wed, 24 Aug 2005 13:04:22 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Subject: [Ips] Discovery reinstatement X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I spent sometime studying previous email threads on this topic and gave the topic some thought. My current thinking and rationale is written below, I hope we'll arrive at a consensus on this topic this time...... In short, I'm leaning towards not saying anything on discovery reinstatement in the Implementer's guide, but still open to being persuaded otherwise. Sorry it's a long note. [Options: A. TPGTs are always Node-scoped. If Node name isn't specified in the discovery Login Request PDU, TPGT is meaningless and can't be inferred (or inferred to be invalid). B. TPGTs are always Node-scoped. If Node name isn't specified in the discovery Login Request PDU, a special "No-Name" iSCSI Node is implied. This No-Name iSCSI Node has its own TPGT numbering space - one tag for each physically possible portal group - and thus the TPGT can be inferred. ] Question 1: Is it desirable that an initiator precisely know in advance when a new discovery session might reinstate an existing discovery session (with the same Network Entity)? Yes (based on the plugfest feedback), so let's analyze what this leads us to. If I got this wrong, feel free to reset me (especially to Bob Russell). If the answer is no, then the whole discussion is moot (jump down to the conclusions). Question 2: If so, how would the initiator deterministically know what reinstates what? Option A: Assuming a fixed InitiatorName and ISID pair, a new no-named discovery session will reinstate an old no-named discovery session if the following is met: (1) servicing iSCSI Portal (for the new session) is hosted by the same Network Entity as that of the existing session. Option B: Assuming a fixed InitiatorName and ISID pair, a new no-named discovery session will reinstate an old no-named discovery session if the following are met: (1) servicing iSCSI Portal (for the new session) is hosted by the same Network Entity as that of the existing session, and, (2) TPGT of the servicing iSCSI Portal (for the new session) matches that of the existing session. Question 3: Can the conditions for each option be met? Condition (1) can be met if we assume that the initiator has a (non-iSCSI) way of discovering that two IP addresses are hosted by one remote system (i.e. iSCSI Network Entity). Condition (2) for realizing Option B however cannot be met because TPGT is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the absence of a node name nor a way to communicate them to the initiator apriori. Besides, there's a bootstrapping problem in that a discovery session is needed to find out TPGT associations. So I believe condition (2) cannot be met, and thus do not see a way to support Option.B *given* the desire that the initiator deterministically predict session reinstatement in advance (answer to Question.1). To summarize: I see four possibilities (in decreasing order of my preference): I. We reject the assertion that initiator should be able to deterministically predict session reinstatement. So say nothing about this topic in the Implementer's guide. II. We accept the assertion. So mandate Option A in Implementer's guide. III.We "semi-accept" the assertion by saying that the initiator cannot predict reinstatement in advance but will know why a reinstatement happened post-fact (because the new session returned the same TPGT as did an existing no-named session). So mandate Option B in Implementer's guide. IV. We reject the assertion. Specify both Option A and Option B in the Implementer's guide. And leave it to implementer's discretion. I am personally fine with either I or II but not motivated to go to III because it does not satisfy the "predict in advance" desire even while it requires enhancements/changes to RFC 3720 (and by extension, to some existing implementations): a) allow a No-Name target node (i.e. a node that maps 1-to-1 with Network Entity) b) explicitly allow a TPGT numbering space for a No-Name target c) mandate returning TPGT on no-named discovery sessions. d) deal with second-order questions such as: shouldn't the No-Name target information be returned in SendTargets response? how about target port names for No-Name target node? .... The net is that I see very little ROI in III. I again see little ROI in IV. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 24 17:54:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83CV-0001L0-Dr; Wed, 24 Aug 2005 17:54:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83CT-0001Iy-B2 for ips@megatron.ietf.org; Wed, 24 Aug 2005 17:54:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23575 for ; Wed, 24 Aug 2005 17:54:23 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E83Cq-0001Nj-SF for ips@ietf.org; Wed, 24 Aug 2005 17:54:50 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 9195F87081; Wed, 24 Aug 2005 17:54:10 -0400 (EDT) In-Reply-To: <430CD2C6.4050506@rose.hp.com> References: <430CD2C6.4050506@rose.hp.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <767efc74bce5ba1149369cdfbcecc91d@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery reinstatement Date: Wed, 24 Aug 2005 14:54:00 -0700 To: "Mallikarjun C." X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0295728698==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============0295728698== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10-584352108" Content-Transfer-Encoding: 7bit --Apple-Mail-10-584352108 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 24, 2005, at 1:04 PM, Mallikarjun C. wrote: > I spent sometime studying previous email threads on this topic and > gave the topic some thought. My current thinking and rationale is > written below, I hope we'll arrive at a consensus on this topic this > time...... > > In short, I'm leaning towards not saying anything on discovery > reinstatement in the Implementer's guide, but still open to being > persuaded otherwise. Sorry it's a long note. > > [Options: > > A. TPGTs are always Node-scoped. If Node name isn't specified in the > discovery Login Request PDU, TPGT is meaningless and can't be inferred > (or inferred to be invalid). > > B. TPGTs are always Node-scoped. If Node name isn't specified in the > discovery Login Request PDU, a special "No-Name" iSCSI Node is > implied. This No-Name iSCSI Node has its own TPGT numbering space - > one tag for each physically possible portal group - and thus the TPGT > can be inferred. ] > > > Question 1: > Is it desirable that an initiator precisely know in advance when a new > discovery session might reinstate an existing discovery session (with > the same Network Entity)? > > Yes (based on the plugfest feedback), so let's analyze what this leads > us to. If I got this wrong, feel free to reset me (especially to Bob > Russell). Can we get more information on the basis for this desire? I think knowing why folks wanted this will help us decide what to do. > If the answer is no, then the whole discussion is moot (jump down to > the > conclusions). I'd like to throw in a bit of a qualification here. I see two variations to the "not know in advance" idea. There is the variation where the initiator thought the new session would reinstate an existing one but didn't (due to TPGT information received as part of login) and then there's the variation where the initiator thought a new session would not reinstate an old one but it did. I think that not reinstating when the initiator thought it might is less severe than reinstating when the initiator thought it shouldn't. > Question 2: > If so, how would the initiator deterministically know what reinstates > what? > > Option A: > Assuming a fixed InitiatorName and ISID pair, a new no-named discovery > session will reinstate an old no-named discovery session if the > following is met: > (1) servicing iSCSI Portal (for the new session) is hosted by the > same Network Entity as that of the existing session. > > Option B: > Assuming a fixed InitiatorName and ISID pair, a new no-named discovery > session will reinstate an old no-named discovery session if the > following are met: > (1) servicing iSCSI Portal (for the new session) is hosted by the > same Network Entity as that of the existing session, and, > > (2) TPGT of the servicing iSCSI Portal (for the new session) matches > that of the existing session. > > Question 3: > Can the conditions for each option be met? > > Condition (1) can be met if we assume that the initiator has a > (non-iSCSI) way of discovering that two IP addresses are hosted > by one remote system (i.e. iSCSI Network Entity). > > Condition (2) for realizing Option B however cannot be met because TPGT > is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the > absence of a node name nor a way to communicate them to the initiator > apriori. Besides, there's a bootstrapping problem in that a discovery > session is needed to find out TPGT associations. > > So I believe condition (2) cannot be met, and thus do not see a way to > support Option.B *given* the desire that the initiator > deterministically > predict session reinstatement in advance (answer to Question.1). I think I agree with your analysis. While the non-iSCSI way of discovering network entity affiliation from condition 1 could also indicate TPGT sense, I feel it'd be fragile. > To summarize: > > I see four possibilities (in decreasing order of my preference): > > I. We reject the assertion that initiator should be able to > deterministically predict session reinstatement. So say > nothing about this topic in the Implementer's guide. I think I agree with rejecting this assertion, but I would soften it to be that the initiator should expect reinstatement but could be told after the fact (as part of the initial login response) that reinstatement did not happen. Yes, this is the "semi-accept" except that the initiator should always expect reinstatement. As for saying nothing, that would be fine. It would be nice, however, if we could relax the text regarding the TargetPortalGroupTag to indicate that a target MAY send a TPGT when no TargetName was specified by the initiator if the target keeps TPGTs for discovery sessions. > II. We accept the assertion. So mandate Option A in Implementer's > guide. I think this would be hard for some implementations. Doable, but hard. > III.We "semi-accept" the assertion by saying that the initiator cannot > predict reinstatement in advance but will know why a reinstatement > happened post-fact (because the new session returned the same TPGT > as did an existing no-named session). So mandate Option B in > Implementer's guide. > > IV. We reject the assertion. Specify both Option A and Option B in the > Implementer's guide. And leave it to implementer's discretion. Note that I think options III and IV are really the same. My thoughts include "no TPGT" as a "valid" TPGT for discovery, so option A is a special case of option B. :-) > I am personally fine with either I or II but not motivated to go to III > because it does not satisfy the "predict in advance" desire even > while it requires enhancements/changes to RFC 3720 (and by extension, > to > some existing implementations): > a) allow a No-Name target node (i.e. a node that maps 1-to-1 > with Network Entity) > b) explicitly allow a TPGT numbering space for a No-Name target > c) mandate returning TPGT on no-named discovery sessions. As per above, I think "no TPGT" implicitly is a TPGT for this, so existing implementations are in-spec. So I don't think we need to _mandate_ this change. I'd like to allow it, but not mandate it. > d) deal with second-order questions such as: shouldn't the > No-Name target information be returned in SendTargets response? > how about target port names for No-Name target node? .... I agree that kind of question is a bit silly. You aren't supposed to keep discovery sessions open, so you shouldn't really care about reinstatement on them. You can, but you get what you get. I'm not sure what I think at this point. While I like option III, option I would be fine too. There is something to be said for not opening the can of worms. Take care, Bill --Apple-Mail-10-584352108 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDDOx+DJT2Egh26K0RAuh8AJwLirVwyzneoSH+TUhIK9ZJdlTI/QCeOUV9 NzMku+4QlvkDutqonEitxi8= =QX+Q -----END PGP SIGNATURE----- --Apple-Mail-10-584352108-- --===============0295728698== 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 --===============0295728698==-- From ips-bounces@ietf.org Wed Aug 24 20:42:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E85pa-0006fk-GK; Wed, 24 Aug 2005 20:42:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E85pY-0006f4-Ro for ips@megatron.ietf.org; Wed, 24 Aug 2005 20:42:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06424 for ; Wed, 24 Aug 2005 20:42:55 -0400 (EDT) Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E85py-0007Z4-Vq for ips@ietf.org; Wed, 24 Aug 2005 20:43:23 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel9.hp.com (Postfix) with ESMTP id A5B2A15DDE for ; Wed, 24 Aug 2005 20:42:55 -0400 (EDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.40]) by rosemail.rose.hp.com (Postfix) with ESMTP id BC3AD825A for ; Wed, 24 Aug 2005 17:40:56 -0700 (PDT) Message-ID: <430D140D.9060407@rose.hp.com> Date: Wed, 24 Aug 2005 17:42:53 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] Login Phase in iSER over IB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Alex, > The only explicit sanctioning here is the requirement to use the same > connection on the > transport level both for the login and the full-featured phases: I am fine with that requirement. This is strongly implied in RFC 3720 and the current iSER draft, and does not create any new dependencies by itself. My concern was about mandating the second statement: "....For a transport layer that provides message delivery capability, such as [IB], the iSCSI Layer MUST interact with the transport layer directly". I strongly recommend that this statement be deferred to IBTA's iSER/IB RC document that presumably complements the IETF iSER draft, rather than include it in the iSER draft. IMO, there is no technical reason to include the 2nd statement in iSER draft now at the risk of getting tangled up in the dependency chains on the IBTA draft. iSER draft was deemed indirectly normatively dependent on MPA sometime ago because RFC 3720 only defines iSCSI/TCP and MPA is thus indirectly required for iSER. I do not now want the iSER draft to enter into an indirect dependency chain on the IBTA draft by mandating something that RFC 3720 does not define today. From a spec perspective, the "must use same connection for login and FFP" language in iSER draft (which I agree with) gives the IBTA document authors requisite authority to mandate the other part. Thanks. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Alex Nezhinsky wrote: > Mallikarjun C. wrote: > >>I do not however think that iSER draft should explicitly sanction a > > new iSCSI/MDT > >>login mechanism now unless it can reference at least one standard that > > defines such > >>a login mechanism. My concern with such a reference would be the > > normative > >>dependency and the potential delay. > > > Mallikarjun, > > The only explicit sanctioning here is the requirement to use the same > connection on the > transport level both for the login and the full-featured phases: > >>The same connection MUST be used for both the iSCSI Login phase and > > the subsequent > >>iSER-supported Full-Feature phase > > > This may be achieved in many ways, and the only thing which was intended > to be avoided was > opening one stream-based connection (like IPoIB) for the Login phase and > then going on with > a (different) MDT-based connection (like IB RC) for the Full-Feature > phase. > Such option was proposed by many readers or potential implementers (the > last post > with such proposal that I read has been issued today) as an intuitive > reaction to the lack of > stream support in IB RC. > > I believe that you do not have to reference a standard that explicitely > defines a new login > mechanism, only warn that any such mechanism has to use a single > transport connection. > > Alexander Nezhinsky > > Software Engineer > Infiniband Storage Solutions > http://www.voltaire.com/ > 9 Ha-Menofim, Herzelya 46725 Israel > tel: +972- 9- 9717637 > fax: +972- 9- 9717660 > mobile: +972-50-7504376 > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 25 08:03:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8GSW-0000uK-Pt; Thu, 25 Aug 2005 08:03:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8GST-0000uE-AQ for ips@megatron.ietf.org; Thu, 25 Aug 2005 08:03:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14416 for ; Thu, 25 Aug 2005 08:03:45 -0400 (EDT) Received: from volter-fw.ser.netvision.net.il ([212.143.107.30] helo=taurus.voltaire.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8GSv-0000tJ-QD for ips@ietf.org; Thu, 25 Aug 2005 08:04:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ips] Login Phase in iSER over IB Date: Thu, 25 Aug 2005 15:03:16 +0300 Message-ID: Thread-Topic: Re: [Ips] Login Phase in iSER over IB Thread-Index: AcWpbPogL6zh7zcvQGmbPrEyVEgW7A== From: "Alex Nezhinsky" To: "Mallikarjun C." , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Mallikarjun, >> The only explicit sanctioning here is the requirement to use the same >> connection on the transport level both for the login and the=20 >> full-featured phases: > I am fine with that requirement. This is strongly implied in RFC 3720 > and the current iSER draft, and does not create any new dependencies=20 > My concern was about mandating the second statement: "....For a=20 > transport layer that provides message delivery capability, such as=20 > [IB], the iSCSI Layer MUST interact with the transport layer directly".=20 Well, to summarize: In 3.1.6: "...the RDMA-Capable Protocol implementation supports the=20 use of this messaging capability by the iSCSI Layer directly..."=20 is ok, as it speaks of a possible support for the direct interaction, not mandating it. In 3.1.6.1, we can eliminate the word "directly" (leaving the "MUST") or eliminate both, like this: "...such as [IB], the iSCSI Layer interacts=20 with the transport layer to use the messaging capability..." Anyway, the last statement in 3.1.6.1 remains: "The same connection=20 MUST be used for both the iSCSI Login phase and the subsequent=20 iSER-supported Full-Feature phase." What do you think? =20 Alexander Nezhinsky =20 Software Engineer Infiniband Storage Solutions =20 9 Ha-Menofim, Herzelya 46725 Israel tel: +972- 9- 9717637 fax: +972- 9- 9717660 mobile: +972-50-7504376 =20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Aug 25 13:28:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8LWu-000153-LG; Thu, 25 Aug 2005 13:28:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8LWs-00014v-Tw for ips@megatron.ietf.org; Thu, 25 Aug 2005 13:28:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01667 for ; Thu, 25 Aug 2005 13:28:37 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8LXN-0002PY-2u for ips@ietf.org; Thu, 25 Aug 2005 13:29:15 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel12.hp.com (Postfix) with ESMTP id 0D79340288E for ; Thu, 25 Aug 2005 10:28:33 -0700 (PDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.40]) by rosemail.rose.hp.com (Postfix) with ESMTP id 39EA18317 for ; Thu, 25 Aug 2005 10:26:32 -0700 (PDT) Message-ID: <430DFFBF.8010707@rose.hp.com> Date: Thu, 25 Aug 2005 10:28:31 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] Login Phase in iSER over IB References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > What do you think? I think leaving out that statement in its entirety is the right thing. In normalizing the iSER spec out of iWARP-specifics (which I fully support), we've to be cautious not to introduce IB-specifics into the iSER draft. > Anyway, the last statement in 3.1.6.1 remains: Agreed, with one editorial - s/iSER-supported/iSER-assisted/. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Alex Nezhinsky wrote: > Mallikarjun, > > >>>The only explicit sanctioning here is the requirement to use the same >>>connection on the transport level both for the login and the >>>full-featured phases: > > >>I am fine with that requirement. This is strongly implied in RFC 3720 >>and the current iSER draft, and does not create any new dependencies > > >>My concern was about mandating the second statement: "....For a >>transport layer that provides message delivery capability, such as >>[IB], the iSCSI Layer MUST interact with the transport layer > > directly". > > Well, to summarize: > > In 3.1.6: "...the RDMA-Capable Protocol implementation supports the > use of this messaging capability by the iSCSI Layer directly..." > is ok, as it speaks of a possible support for the direct interaction, > not mandating it. > > In 3.1.6.1, we can eliminate the word "directly" (leaving the "MUST") or > > eliminate both, like this: "...such as [IB], the iSCSI Layer interacts > with the transport layer to use the messaging capability..." > > Anyway, the last statement in 3.1.6.1 remains: "The same connection > MUST be used for both the iSCSI Login phase and the subsequent > iSER-supported Full-Feature phase." > > What do you think? > > Alexander Nezhinsky > > Software Engineer > Infiniband Storage Solutions > > 9 Ha-Menofim, Herzelya 46725 Israel > tel: +972- 9- 9717637 > fax: +972- 9- 9717660 > mobile: +972-50-7504376 > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 29 02:56:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dZ7-0003vL-NL; Mon, 29 Aug 2005 02:56:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9dZ6-0003vD-QM for ips@megatron.ietf.org; Mon, 29 Aug 2005 02:56:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20032 for ; Mon, 29 Aug 2005 02:56:19 -0400 (EDT) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9daO-0004p4-QW for ips@ietf.org; Mon, 29 Aug 2005 02:57:41 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j7T6u6TZ180820 for ; Mon, 29 Aug 2005 06:56:06 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7T6u6Qg040768 for ; Mon, 29 Aug 2005 08:56:06 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j7T6u5Ml031760 for ; Mon, 29 Aug 2005 08:56:05 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j7T6u58i031749; Mon, 29 Aug 2005 08:56:05 +0200 In-Reply-To: <8320074d0508180925358aba7d@mail.gmail.com> To: Rohan Sen Subject: Re: [Ips] SendTargets sent with other key in Text Request MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_08012005NP August 01, 2005 From: Julian Satran Message-ID: Date: Mon, 29 Aug 2005 09:56:27 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.1| March 5, 2004) at 29/08/2005 09:56:04, Serialize complete at 29/08/2005 09:56:04 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: ISCSI X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1855567381==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1855567381== Content-Type: multipart/alternative; boundary="=_alternative 00242518C225706C_=" This is a multipart message in MIME format. --=_alternative 00242518C225706C_= Content-Type: text/plain; charset="US-ASCII" The target should respond with a Reject PDU. It can then choose to continue or close the connection/session a it sees fit. Closing the connection without answering should be reserved for the cases in which a DOS attack is suspected - in which case it will be probably be followed by some initiator (addresses) being blacklisted. Julo Rohan Sen Sent by: ips-bounces@ietf.org 18-08-05 19:25 To ISCSI cc Subject [Ips] SendTargets sent with other key in Text Request What should the Target do if it receives a Text Request PDU in Discover Session containing the following keys : " - SendTargets=All" " - MaxRecvDataSegmentLength=1000" (invalid as per rfc3720 Appendix D Page 229) Should the target send a Reject PDU stating Protocol Error but not close the connection or should it simply close the connection without sending any ISCSI PDU ? -- thanks, Rohan Sen _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00242518C225706C_= Content-Type: text/html; charset="US-ASCII"
The target should respond with a Reject PDU. It can then choose to continue or  close the connection/session a it sees fit.
Closing the connection without answering should be reserved for the cases in which a DOS attack is suspected - in which case it will be probably be followed by some initiator (addresses) being blacklisted.

Julo


Rohan Sen <senrohan@gmail.com>
Sent by: ips-bounces@ietf.org

18-08-05 19:25

To
ISCSI <ips@ietf.org>
cc
Subject
[Ips] SendTargets sent with other key in Text Request





What should the Target do if it receives a Text Request PDU in
Discover Session containing the following keys :

"        - SendTargets=All"
"        - MaxRecvDataSegmentLength=1000" (invalid as per rfc3720
Appendix D Page 229)

Should the target send a Reject PDU stating Protocol Error but not
close the connection or
should it simply close the connection without sending any ISCSI PDU ?
--
thanks,
Rohan Sen

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00242518C225706C_=-- --===============1855567381== 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 --===============1855567381==-- From ips-bounces@ietf.org Mon Aug 29 09:00:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jFv-0004EC-54; Mon, 29 Aug 2005 09:00:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jFt-0004E2-NY for ips@megatron.ietf.org; Mon, 29 Aug 2005 09:00:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06108 for ; Mon, 29 Aug 2005 09:00:52 -0400 (EDT) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9jHF-0006zz-0J for ips@ietf.org; Mon, 29 Aug 2005 09:02:17 -0400 Received: from ivvt2dxrc11 (c-66-177-46-192.hsd1.fl.comcast.net[66.177.46.192]) by comcast.net (rwcrmhc11) with SMTP id <200508291300400130061p7fe>; Mon, 29 Aug 2005 13:00:40 +0000 Message-ID: <000701c5ac99$a8b364f0$03031eac@ivivity.com> From: "Eddy Quicksall" To: "Mallikarjun C." , "IPS" References: <430CD2C6.4050506@rose.hp.com> Subject: Re: [Ips] Discovery reinstatement Date: Mon, 29 Aug 2005 09:00:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org FYI, I believe Dr Russell is on a one year sabbatical. Eddy ----- Original Message ----- From: "Mallikarjun C." To: "IPS" Sent: Wednesday, August 24, 2005 4:04 PM Subject: [Ips] Discovery reinstatement >I spent sometime studying previous email threads on this topic and gave the >topic some thought. My current thinking and rationale is written below, I >hope we'll arrive at a consensus on this topic this time...... > > In short, I'm leaning towards not saying anything on discovery > reinstatement in the Implementer's guide, but still open to being > persuaded otherwise. Sorry it's a long note. > > [Options: > > A. TPGTs are always Node-scoped. If Node name isn't specified in the > discovery Login Request PDU, TPGT is meaningless and can't be inferred (or > inferred to be invalid). > > B. TPGTs are always Node-scoped. If Node name isn't specified in the > discovery Login Request PDU, a special "No-Name" iSCSI Node is implied. > This No-Name iSCSI Node has its own TPGT numbering space - one tag for > each physically possible portal group - and thus the TPGT can be > inferred. ] > > > Question 1: > Is it desirable that an initiator precisely know in advance when a new > discovery session might reinstate an existing discovery session (with > the same Network Entity)? > > Yes (based on the plugfest feedback), so let's analyze what this leads us > to. If I got this wrong, feel free to reset me (especially to Bob > Russell). > > If the answer is no, then the whole discussion is moot (jump down to the > conclusions). > > Question 2: > If so, how would the initiator deterministically know what reinstates > what? > > Option A: > Assuming a fixed InitiatorName and ISID pair, a new no-named discovery > session will reinstate an old no-named discovery session if the > following is met: > (1) servicing iSCSI Portal (for the new session) is hosted by the > same Network Entity as that of the existing session. > > Option B: > Assuming a fixed InitiatorName and ISID pair, a new no-named discovery > session will reinstate an old no-named discovery session if the > following are met: > (1) servicing iSCSI Portal (for the new session) is hosted by the > same Network Entity as that of the existing session, and, > > (2) TPGT of the servicing iSCSI Portal (for the new session) matches > that of the existing session. > > Question 3: > Can the conditions for each option be met? > > Condition (1) can be met if we assume that the initiator has a > (non-iSCSI) way of discovering that two IP addresses are hosted > by one remote system (i.e. iSCSI Network Entity). > > Condition (2) for realizing Option B however cannot be met because TPGT > is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the > absence of a node name nor a way to communicate them to the initiator > apriori. Besides, there's a bootstrapping problem in that a discovery > session is needed to find out TPGT associations. > > So I believe condition (2) cannot be met, and thus do not see a way to > support Option.B *given* the desire that the initiator deterministically > predict session reinstatement in advance (answer to Question.1). > > > To summarize: > > I see four possibilities (in decreasing order of my preference): > > I. We reject the assertion that initiator should be able to > deterministically predict session reinstatement. So say > nothing about this topic in the Implementer's guide. > > II. We accept the assertion. So mandate Option A in Implementer's > guide. > > III.We "semi-accept" the assertion by saying that the initiator cannot > predict reinstatement in advance but will know why a reinstatement > happened post-fact (because the new session returned the same TPGT > as did an existing no-named session). So mandate Option B in > Implementer's guide. > > IV. We reject the assertion. Specify both Option A and Option B in the > Implementer's guide. And leave it to implementer's discretion. > > I am personally fine with either I or II but not motivated to go to III > because it does not satisfy the "predict in advance" desire even > while it requires enhancements/changes to RFC 3720 (and by extension, to > some existing implementations): > a) allow a No-Name target node (i.e. a node that maps 1-to-1 > with Network Entity) > b) explicitly allow a TPGT numbering space for a No-Name target > c) mandate returning TPGT on no-named discovery sessions. > d) deal with second-order questions such as: shouldn't the > No-Name target information be returned in SendTargets response? > how about target port names for No-Name target node? .... > > The net is that I see very little ROI in III. > > I again see little ROI in IV. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 29 10:48:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kve-0001LV-3H; Mon, 29 Aug 2005 10:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kvc-0001LI-6B for ips@megatron.ietf.org; Mon, 29 Aug 2005 10:48:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14510 for ; Mon, 29 Aug 2005 10:48:02 -0400 (EDT) Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9kwx-00026L-Dr for ips@ietf.org; Mon, 29 Aug 2005 10:49:28 -0400 Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by io.iol.unh.edu (8.13.4/8.13.4) with ESMTP id j7TElmeM001273; Mon, 29 Aug 2005 10:47:48 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.13.4/8.13.4/Submit) with ESMTP id j7TElmO7001270; Mon, 29 Aug 2005 10:47:48 -0400 Date: Mon, 29 Aug 2005 10:47:48 -0400 (EDT) From: "Robert D. Russell" To: Eddy Quicksall Subject: Re: [Ips] Discovery reinstatement In-Reply-To: <000701c5ac99$a8b364f0$03031eac@ivivity.com> Message-ID: References: <430CD2C6.4050506@rose.hp.com> <000701c5ac99$a8b364f0$03031eac@ivivity.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-UNH-IOL-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-UNH-IOL-MailScanner: Found to be clean X-UNH-IOL-MailScanner-From: rdr@io.iol.unh.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: IPS , "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Eddy, Mallikarjun: > FYI, I believe Dr Russell is on a one year sabbatical. True, and your last e-mail caught me in transit without reliable e-mail access -- sorry about that. > >> I spent sometime studying previous email threads on this topic and gave the >> topic some thought. My current thinking and rationale is written below, I >> hope we'll arrive at a consensus on this topic this time...... >> >> In short, I'm leaning towards not saying anything on discovery >> reinstatement in the Implementer's guide, but still open to being persuaded >> otherwise. Sorry it's a long note. >> >> [Options: >> >> A. TPGTs are always Node-scoped. If Node name isn't specified in the >> discovery Login Request PDU, TPGT is meaningless and can't be inferred (or >> inferred to be invalid). >> >> B. TPGTs are always Node-scoped. If Node name isn't specified in the >> discovery Login Request PDU, a special "No-Name" iSCSI Node is implied. >> This No-Name iSCSI Node has its own TPGT numbering space - one tag for each >> physically possible portal group - and thus the TPGT can be inferred. ] >> >> >> Question 1: >> Is it desirable that an initiator precisely know in advance when a new >> discovery session might reinstate an existing discovery session (with >> the same Network Entity)? >> >> Yes (based on the plugfest feedback), so let's analyze what this leads us >> to. If I got this wrong, feel free to reset me (especially to Bob >> Russell). >> >> If the answer is no, then the whole discussion is moot (jump down to the >> conclusions). There was not any reliable plugfest data on this issue. What we encountered were situations where there was interference between Normal Sessions and Discovery Sessions (i.e., where a Normal Session would reinstate a Discovery Session, and vice versa). That was what was originally discussed on the reflector just about a year ago, and at that time the issue of multiple simultaneous Discovery Sessions between the same initiator and target never came up. What led to the current discussion was my suggestion of a few months ago to add to the implementor's guide the resolution of a non-name target for Discovery sessions, and that brought the realization that the TPGT issue had never been discussed before and therefore had not been resolved. I suggested that the TPGT value be NULL or empty, because that seemed to be in the spirit of discovery (as also suggested by Julian), but that was only a suggestion. My 2-cents worth on the issue is that it is desirable for the initiator to be able to deterministically know in advance when a discovery session will be reinstated, because otherwise there are unexpected surprises that can lead to interoperability issues. (I believe there have been postings about infinite loops being triggered.) Non-determinism also makes it more complex for the initiator to deal with, which invariably can cause otherwise compatible initiator-target pairs to stop interoperating (the added complexity also hides bugs). Thus I would be in favor of mandating Option A (your conclusion II below), as being least problematic and most in the spirit of the original intentions of the RFC 3720 designers. If your conclusion I below is accepted, I believe you should at least say something about it in the implementer's guide, even if only to warn implementers that there is this whole bag of worms to watch out for. Thanks, Bob >> >> Question 2: >> If so, how would the initiator deterministically know what reinstates >> what? >> >> Option A: >> Assuming a fixed InitiatorName and ISID pair, a new no-named discovery >> session will reinstate an old no-named discovery session if the >> following is met: >> (1) servicing iSCSI Portal (for the new session) is hosted by the >> same Network Entity as that of the existing session. >> >> Option B: >> Assuming a fixed InitiatorName and ISID pair, a new no-named discovery >> session will reinstate an old no-named discovery session if the >> following are met: >> (1) servicing iSCSI Portal (for the new session) is hosted by the >> same Network Entity as that of the existing session, and, >> >> (2) TPGT of the servicing iSCSI Portal (for the new session) matches >> that of the existing session. >> >> Question 3: >> Can the conditions for each option be met? >> >> Condition (1) can be met if we assume that the initiator has a >> (non-iSCSI) way of discovering that two IP addresses are hosted >> by one remote system (i.e. iSCSI Network Entity). >> >> Condition (2) for realizing Option B however cannot be met because TPGT >> is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the >> absence of a node name nor a way to communicate them to the initiator >> apriori. Besides, there's a bootstrapping problem in that a discovery >> session is needed to find out TPGT associations. >> >> So I believe condition (2) cannot be met, and thus do not see a way to >> support Option.B *given* the desire that the initiator deterministically >> predict session reinstatement in advance (answer to Question.1). >> >> >> To summarize: >> >> I see four possibilities (in decreasing order of my preference): >> >> I. We reject the assertion that initiator should be able to >> deterministically predict session reinstatement. So say >> nothing about this topic in the Implementer's guide. >> >> II. We accept the assertion. So mandate Option A in Implementer's >> guide. >> >> III.We "semi-accept" the assertion by saying that the initiator cannot >> predict reinstatement in advance but will know why a reinstatement >> happened post-fact (because the new session returned the same TPGT >> as did an existing no-named session). So mandate Option B in >> Implementer's guide. >> >> IV. We reject the assertion. Specify both Option A and Option B in the >> Implementer's guide. And leave it to implementer's discretion. >> >> I am personally fine with either I or II but not motivated to go to III >> because it does not satisfy the "predict in advance" desire even >> while it requires enhancements/changes to RFC 3720 (and by extension, to >> some existing implementations): >> a) allow a No-Name target node (i.e. a node that maps 1-to-1 >> with Network Entity) >> b) explicitly allow a TPGT numbering space for a No-Name target >> c) mandate returning TPGT on no-named discovery sessions. >> d) deal with second-order questions such as: shouldn't the >> No-Name target information be returned in SendTargets response? >> how about target port names for No-Name target node? .... >> >> The net is that I see very little ROI in III. >> >> I again see little ROI in IV. >> -- >> Mallikarjun >> >> Mallikarjun Chadalapaka >> Networked Storage Architecture >> StorageWorks Division >> Hewlett-Packard MS 5668 >> Roseville CA 95747 >> cbm [at] rose.hp.com >> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 29 15:33:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pNz-00022d-Dd; Mon, 29 Aug 2005 15:33:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pNw-00022X-0z for ips@megatron.ietf.org; Mon, 29 Aug 2005 15:33:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01752 for ; Mon, 29 Aug 2005 15:33:32 -0400 (EDT) Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9pPI-0002aQ-By for ips@ietf.org; Mon, 29 Aug 2005 15:35:00 -0400 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel9.hp.com (Postfix) with ESMTP id 3FE6AAFA5 for ; Mon, 29 Aug 2005 15:33:32 -0400 (EDT) Received: from [127.0.0.1] (sindhu.americas.hpqcorp.net [16.93.44.40]) by rosemail.rose.hp.com (Postfix) with ESMTP id 29B7A8251 for ; Mon, 29 Aug 2005 12:31:12 -0700 (PDT) Message-ID: <43136307.1060206@rose.hp.com> Date: Mon, 29 Aug 2005 12:33:27 -0700 From: "Mallikarjun C." User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPS Subject: Re: [Ips] Discovery reinstatement References: <430CD2C6.4050506@rose.hp.com> <000701c5ac99$a8b364f0$03031eac@ivivity.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: 7bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org > My 2-cents worth on the issue is that it is desirable for the > initiator to be able to deterministically know in advance when > a discovery session will be reinstated..... > Thus I would be in favor of mandating Option A (your conclusion II below), > as being least problematic and most in the spirit of the original > intentions of the RFC 3720 designers. Thanks for the feedback. I am personally fine with II (II lags I only by a little in my preference scale, that too only if I do not need to add any "bag of worms" text in adopting I). Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture StorageWorks Division Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Robert D. Russell wrote: > Eddy, Mallikarjun: > >> FYI, I believe Dr Russell is on a one year sabbatical. > > True, and your last e-mail caught me in transit without > reliable e-mail access -- sorry about that. > > >> >>> I spent sometime studying previous email threads on this topic and >>> gave the topic some thought. My current thinking and rationale is >>> written below, I hope we'll arrive at a consensus on this topic this >>> time...... >>> >>> In short, I'm leaning towards not saying anything on discovery >>> reinstatement in the Implementer's guide, but still open to being >>> persuaded otherwise. Sorry it's a long note. >>> >>> [Options: >>> >>> A. TPGTs are always Node-scoped. If Node name isn't specified in the >>> discovery Login Request PDU, TPGT is meaningless and can't be >>> inferred (or inferred to be invalid). >>> >>> B. TPGTs are always Node-scoped. If Node name isn't specified in the >>> discovery Login Request PDU, a special "No-Name" iSCSI Node is >>> implied. This No-Name iSCSI Node has its own TPGT numbering space - >>> one tag for each physically possible portal group - and thus the TPGT >>> can be inferred. ] >>> >>> >>> Question 1: >>> Is it desirable that an initiator precisely know in advance when a new >>> discovery session might reinstate an existing discovery session (with >>> the same Network Entity)? >>> >>> Yes (based on the plugfest feedback), so let's analyze what this >>> leads us to. If I got this wrong, feel free to reset me (especially >>> to Bob Russell). >>> >>> If the answer is no, then the whole discussion is moot (jump down to the >>> conclusions). > > > There was not any reliable plugfest data on this issue. > What we encountered were situations where there was interference > between Normal Sessions and Discovery Sessions (i.e., where a > Normal Session would reinstate a Discovery Session, and vice versa). > That was what was originally discussed on the reflector just about > a year ago, and at that time the issue of multiple simultaneous > Discovery Sessions between the same initiator and target never came > up. What led to the current discussion was my suggestion of a few months > ago to add to the implementor's guide the resolution of a > non-name target for Discovery sessions, and that brought the realization > that the TPGT issue had never been discussed before and therefore > had not been resolved. I suggested that the TPGT value be NULL > or empty, because that seemed to be in the spirit of discovery > (as also suggested by Julian), but that was only a suggestion. > > My 2-cents worth on the issue is that it is desirable for the > initiator to be able to deterministically know in advance when > a discovery session will be reinstated, because otherwise there > are unexpected surprises that can lead to interoperability issues. > (I believe there have been postings about infinite loops being > triggered.) Non-determinism also makes it more complex for the > initiator to deal with, which invariably can cause otherwise > compatible initiator-target pairs to stop interoperating > (the added complexity also hides bugs). > > Thus I would be in favor of mandating Option A (your conclusion II below), > as being least problematic and most in the spirit of the original > intentions of the RFC 3720 designers. > > If your conclusion I below is accepted, I believe you should at least > say something about it in the implementer's guide, even if only to warn > implementers that there is this whole bag of worms to watch out for. > > Thanks, > Bob > >>> >>> Question 2: >>> If so, how would the initiator deterministically know what reinstates >>> what? >>> >>> Option A: >>> Assuming a fixed InitiatorName and ISID pair, a new no-named discovery >>> session will reinstate an old no-named discovery session if the >>> following is met: >>> (1) servicing iSCSI Portal (for the new session) is hosted by the >>> same Network Entity as that of the existing session. >>> >>> Option B: >>> Assuming a fixed InitiatorName and ISID pair, a new no-named discovery >>> session will reinstate an old no-named discovery session if the >>> following are met: >>> (1) servicing iSCSI Portal (for the new session) is hosted by the >>> same Network Entity as that of the existing session, and, >>> >>> (2) TPGT of the servicing iSCSI Portal (for the new session) matches >>> that of the existing session. >>> >>> Question 3: >>> Can the conditions for each option be met? >>> >>> Condition (1) can be met if we assume that the initiator has a >>> (non-iSCSI) way of discovering that two IP addresses are hosted >>> by one remote system (i.e. iSCSI Network Entity). >>> >>> Condition (2) for realizing Option B however cannot be met because TPGT >>> is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the >>> absence of a node name nor a way to communicate them to the initiator >>> apriori. Besides, there's a bootstrapping problem in that a discovery >>> session is needed to find out TPGT associations. >>> >>> So I believe condition (2) cannot be met, and thus do not see a way to >>> support Option.B *given* the desire that the initiator deterministically >>> predict session reinstatement in advance (answer to Question.1). >>> >>> >>> To summarize: >>> >>> I see four possibilities (in decreasing order of my preference): >>> >>> I. We reject the assertion that initiator should be able to >>> deterministically predict session reinstatement. So say >>> nothing about this topic in the Implementer's guide. >>> >>> II. We accept the assertion. So mandate Option A in Implementer's >>> guide. >>> >>> III.We "semi-accept" the assertion by saying that the initiator cannot >>> predict reinstatement in advance but will know why a reinstatement >>> happened post-fact (because the new session returned the same TPGT >>> as did an existing no-named session). So mandate Option B in >>> Implementer's guide. >>> >>> IV. We reject the assertion. Specify both Option A and Option B in the >>> Implementer's guide. And leave it to implementer's discretion. >>> >>> I am personally fine with either I or II but not motivated to go to III >>> because it does not satisfy the "predict in advance" desire even >>> while it requires enhancements/changes to RFC 3720 (and by extension, to >>> some existing implementations): >>> a) allow a No-Name target node (i.e. a node that maps 1-to-1 >>> with Network Entity) >>> b) explicitly allow a TPGT numbering space for a No-Name target >>> c) mandate returning TPGT on no-named discovery sessions. >>> d) deal with second-order questions such as: shouldn't the >>> No-Name target information be returned in SendTargets response? >>> how about target port names for No-Name target node? .... >>> >>> The net is that I see very little ROI in III. >>> >>> I again see little ROI in IV. >>> -- >>> Mallikarjun >>> >>> Mallikarjun Chadalapaka >>> Networked Storage Architecture >>> StorageWorks Division >>> Hewlett-Packard MS 5668 >>> Roseville CA 95747 >>> cbm [at] rose.hp.com >>> >>> >>> _______________________________________________ >>> Ips mailing list >>> Ips@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ips >> >> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips >> _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Aug 29 21:05:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9uYy-0004Hi-Ln; Mon, 29 Aug 2005 21:05:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9uYw-0004HV-94 for ips@megatron.ietf.org; Mon, 29 Aug 2005 21:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27767 for ; Mon, 29 Aug 2005 21:05:16 -0400 (EDT) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9uaN-0006go-FU for ips@ietf.org; Mon, 29 Aug 2005 21:06:47 -0400 Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 13877870A2; Mon, 29 Aug 2005 21:04:59 -0400 (EDT) In-Reply-To: References: <430CD2C6.4050506@rose.hp.com> <000701c5ac99$a8b364f0$03031eac@ivivity.com> Mime-Version: 1.0 (Apple Message framework v622) Message-Id: <11ea0355ebcca59d02ae658abfe94c06@wasabisystems.com> From: William Studenmund Subject: Re: [Ips] Discovery reinstatement Date: Mon, 29 Aug 2005 18:04:48 -0700 To: "Robert D. Russell" X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: IPS , Eddy Quicksall , "Mallikarjun C." X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1248205057==" Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org --===============1248205057== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-1027800700" Content-Transfer-Encoding: 7bit --Apple-Mail-1-1027800700 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Aug 29, 2005, at 7:47 AM, Robert D. Russell wrote: >>> I spent sometime studying previous email threads on this topic and >>> gave the topic some thought. My current thinking and rationale is >>> written below, I hope we'll arrive at a consensus on this topic this >>> time...... >>> In short, I'm leaning towards not saying anything on discovery >>> reinstatement in the Implementer's guide, but still open to being >>> persuaded otherwise. Sorry it's a long note. >>> [Options: >>> A. TPGTs are always Node-scoped. If Node name isn't specified in >>> the discovery Login Request PDU, TPGT is meaningless and can't be >>> inferred (or inferred to be invalid). >>> B. TPGTs are always Node-scoped. If Node name isn't specified in >>> the discovery Login Request PDU, a special "No-Name" iSCSI Node is >>> implied. This No-Name iSCSI Node has its own TPGT numbering space - >>> one tag for each physically possible portal group - and thus the >>> TPGT can be inferred. ] >>> Question 1: >>> Is it desirable that an initiator precisely know in advance when a >>> new >>> discovery session might reinstate an existing discovery session (with >>> the same Network Entity)? >>> Yes (based on the plugfest feedback), so let's analyze what this >>> leads us to. If I got this wrong, feel free to reset me (especially >>> to Bob Russell). >>> If the answer is no, then the whole discussion is moot (jump down to >>> the >>> conclusions). > > There was not any reliable plugfest data on this issue. > What we encountered were situations where there was interference > between Normal Sessions and Discovery Sessions (i.e., where a > Normal Session would reinstate a Discovery Session, and vice versa). > That was what was originally discussed on the reflector just about > a year ago, and at that time the issue of multiple simultaneous > Discovery Sessions between the same initiator and target never came > up. What led to the current discussion was my suggestion of a few > months > ago to add to the implementor's guide the resolution of a > non-name target for Discovery sessions, and that brought the > realization > that the TPGT issue had never been discussed before and therefore > had not been resolved. I suggested that the TPGT value be NULL > or empty, because that seemed to be in the spirit of discovery > (as also suggested by Julian), but that was only a suggestion. > > My 2-cents worth on the issue is that it is desirable for the > initiator to be able to deterministically know in advance when > a discovery session will be reinstated, because otherwise there > are unexpected surprises that can lead to interoperability issues. > (I believe there have been postings about infinite loops being > triggered.) Non-determinism also makes it more complex for the > initiator to deal with, which invariably can cause otherwise > compatible initiator-target pairs to stop interoperating > (the added complexity also hides bugs). I'm confused. The two proposals, as I understand it, are that we either always reinstate, or we sometimes reinstate. Part of my recommendation for the latter is that the initiator should ALWAYS EXPECT reinstatement, and should be "pleasantly surprised" if it does not happen. Also, part of the "sometimes reinstate" option is that the initiator would receive information (a TPGT or no TPGT == NUL group) in the first response that indicates what happened. It's like playing Russian Roulette. You (should) always expect a bullet, yet be pleasantly surprised if there isn't one in the chamber. Since the initiator should always be expecting the same thing, reinstatement, I do not see how such an option (not reinstating) would make life more difficult. The only case I can see is that of an initiator tested solely with a target where each portal was in a different portal group, thus never experiencing reinstatement. But such a target will have difficulties anywhere. Can someone please explain how sometimes not reinstating when it's always expected makes life more difficult? I agree that if we had initiators expecting no reinstatement and then getting confused if/when it happened would lead to these issues. That's why I specifically added the "always expect reinstatement" clause. :-) > Thus I would be in favor of mandating Option A (your conclusion II > below), > as being least problematic and most in the spirit of the original > intentions of the RFC 3720 designers. > > If your conclusion I below is accepted, I believe you should at least > say something about it in the implementer's guide, even if only to warn > implementers that there is this whole bag of worms to watch out for. Agreed. For short-lived discovery sessions, even with parallel discovery it is possible that multiple sessions to the same box will succeed w/o reinstatement (consider the case where an initial login packet is dropped and retransmit doesn't kick in until other sessions have ended). So the initiator will have to deal with getting the same info via different paths anyway. Thus anything that would have happened with unexpected reinstatement would happen otherwise. Take care, Bill --Apple-Mail-1-1027800700 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFDE7C2DJT2Egh26K0RAlg2AKCMDYQQ4rkDWLbqpQNoLzkKTsjKrgCfWhFV afEOulaWrtZIKHiY3DcL038= =7AUt -----END PGP SIGNATURE----- --Apple-Mail-1-1027800700-- --===============1248205057== 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 --===============1248205057==-- From ips-bounces@ietf.org Tue Aug 30 14:16:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAAbH-0007lf-1x; Tue, 30 Aug 2005 14:12:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAAbE-0007gM-EQ for ips@megatron.ietf.org; Tue, 30 Aug 2005 14:12:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28223 for ; Tue, 30 Aug 2005 14:12:41 -0400 (EDT) Received: from host28.istor.com ([66.134.214.28] helo=bobcat1) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAAcm-0000Z1-Pr for ips@ietf.org; Tue, 30 Aug 2005 14:14:22 -0400 Received: from mail1irv.inside.istor.com ([192.168.50.7]) by bobcat1 with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Aug 2005 11:12:27 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Date: Tue, 30 Aug 2005 11:12:27 -0700 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF29001119E68@mail1irv.inside.istor.com> Thread-Topic: Data Out PDU's Thread-Index: AcWtjmDeSwCsCRm5S0WVHjyOknXBPA== From: "Ken Craig" To: X-OriginalArrivalTime: 30 Aug 2005 18:12:27.0599 (UTC) FILETIME=[611A1DF0:01C5AD8E] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [Ips] Data Out PDU's X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I have a question about Data Out PDUs. I, as a Target, have negotiated DataSequenceInOrder and DataPDUInOrder. If I generate a R2T for two Write commands does the spec allow the Data Out PDUs for those two R2T's to be intermingled even though each Data Out PDU is in sequence and in order? Something like: Write Cmd 0 - Data Out PDU - SN #0 Write Cmd 1 - Data Out PDU - SN #0 Write Cmd 0 - Data Out PDU - SN #1 Write Cmd 1 - Data Out PDU - SN #1 Write Cmd 0 - Data Out PDU - SN #2 with Final Bit Write Cmd 1 - Data Out PDU - SN #2 with Final Bit Thanks for your help, Kenneth Ray Craig, Jr. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 30 14:19:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAAhZ-0001vj-Kp; Tue, 30 Aug 2005 14:19:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAAhX-0001vb-Tq for ips@megatron.ietf.org; Tue, 30 Aug 2005 14:19:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28711 for ; Tue, 30 Aug 2005 14:19:14 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAAj8-0000ml-Do for ips@ietf.org; Tue, 30 Aug 2005 14:20:54 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j7UIIwij013814 for ; Tue, 30 Aug 2005 14:18:58 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j7UIIwje013809; Tue, 30 Aug 2005 14:18:58 -0400 Received: from pkoning.equallogic.com ([172.16.1.163]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 14:18:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17172.41745.260474.196649@gargle.gargle.HOWL> Date: Tue, 30 Aug 2005 14:18:57 -0400 From: Paul Koning To: kcraig@istor.com Subject: Re: [Ips] Data Out PDU's References: <7D036BD3216A084DB1BD9D62BCEAF29001119E68@mail1irv.inside.istor.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 30 Aug 2005 18:18:58.0714 (UTC) FILETIME=[4A3987A0:01C5AD8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >>>>> "Ken" == Ken Craig writes: Ken> I have a question about Data Out PDUs. I, as a Target, have Ken> negotiated DataSequenceInOrder and DataPDUInOrder. If I Ken> generate a R2T for two Write commands does the spec allow the Ken> Data Out PDUs for those two R2T's to be intermingled even though Ken> each Data Out PDU is in sequence and in order? Yes -- the ordering requirement is for order within a transfer, i.e., a single write command. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Aug 30 15:28:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABmu-0007Gy-Mu; Tue, 30 Aug 2005 15:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EABmt-0007Gq-Q3 for ips@megatron.ietf.org; Tue, 30 Aug 2005 15:28:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03360 for ; Tue, 30 Aug 2005 15:28:49 -0400 (EDT) Received: from dmz1.silverbacksystems.com ([65.172.158.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EABoT-0002hk-Lz for ips@ietf.org; Tue, 30 Aug 2005 15:30:31 -0400 Received: from dmz1.silverbacksystems.com (localhost [127.0.0.1]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with SMTP id E5B55B987; Tue, 30 Aug 2005 12:27:20 -0700 (PDT) Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id D7780B984; Tue, 30 Aug 2005 12:27:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C5DB37B423; Tue, 30 Aug 2005 12:27:19 -0700 (PDT) Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.6) id 01349-0B6DD703; Tue, 30 Aug 2005 12:27:19 -0700 Received: from duala1.corp.silverbacksystems.com (duala1.corp.silverbacksystems.com [10.0.16.56]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 757407B3CA; Tue, 30 Aug 2005 12:27:19 -0700 (PDT) Subject: Re: [Ips] Data Out PDU's From: Gwendal Grignou To: Paul Koning In-Reply-To: <17172.41745.260474.196649@gargle.gargle.HOWL> References: <7D036BD3216A084DB1BD9D62BCEAF29001119E68@mail1irv.inside.istor.com> <17172.41745.260474.196649@gargle.gargle.HOWL> Content-Type: text/plain Date: Tue, 30 Aug 2005 12:27:02 -0700 Message-Id: <1125430022.10995.17.camel@duala1.corp.silverbacksystems.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.6; AVE: 6.24.0.7; VDF: 6.24.0.88; host: ns.silverbacksystems.com) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ips@ietf.org, kcraig@istor.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org On Tue, 2005-08-30 at 14:18 -0400, Paul Koning wrote: > >>>>> "Ken" == Ken Craig writes: > > Ken> I have a question about Data Out PDUs. I, as a Target, have > Ken> negotiated DataSequenceInOrder and DataPDUInOrder. If I > Ken> generate a R2T for two Write commands does the spec allow the > Ken> Data Out PDUs for those two R2T's to be intermingled even though > Ken> each Data Out PDU is in sequence and in order? > > Yes -- the ordering requirement is for order within a transfer, i.e., > a single write command. I don't think so [10.8]: Within a CONNECTION outstanding R2Ts MUST be fulfilled by the initiator in the order in which they were received. Gwendal. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Aug 31 15:57:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYi4-0007tV-6L; Wed, 31 Aug 2005 15:57:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYi2-0007tH-VT for ips@megatron.ietf.org; Wed, 31 Aug 2005 15:57:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09984 for ; Wed, 31 Aug 2005 15:57:20 -0400 (EDT) Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAYjo-00089L-SF for ips@ietf.org; Wed, 31 Aug 2005 15:59:15 -0400 Received: from [192.168.7.130] (helo=winminx) by hammer with esmtp (Exim 4.12) id 1EAYes-0001qh-00; Wed, 31 Aug 2005 20:54:06 +0100 From: "Ken Sandars" To: "'Mallikarjun C.'" , "'IPS'" Subject: RE: [Ips] Discovery reinstatement Date: Wed, 31 Aug 2005 20:56:56 +0100 Message-ID: <000601c5ae66$277d0890$680115ac@elipsan.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <430CD2C6.4050506@rose.hp.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Hi Mallikarjun, I like your approach to this problem. In my mind the answer to question = 1 is a strong yes, however, I do not like the clause about Network Entity. >From my last posting, I restate: an initiator may not know if two = Portals belong to the same Network Entity. For the purposes of discovery, all it requires prior to establishing the discovery session is each Portal's = TCP addressing information. Without a priori knowledge of which portals are in the same Network = Entity, it would be difficult for an initiator to deterministically know if = starting a discovery session to Portal Y is going to reinstate its existing = discovery session on Portal X. Of the four possibilities you propose, I agree that II is on the path to predictable behaviour. However, I suggest the decision to reinstate a Discovery session should be based upon matching the tuple InitiatorName = + ISID + servicing iSCSI Portal. Hence a Network Entity with four Portals = may carry four discovery sessions simultaneously from the one = InitiatorName+ISID pair (one per Portal). Thanks, Ken=20 Ken Sandars Adaptec UK > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On=20 > Behalf Of Mallikarjun C. > Sent: 24 August 2005 21:04 > To: IPS > Subject: [Ips] Discovery reinstatement >=20 >=20 > I spent sometime studying previous email threads on this=20 > topic and gave=20 > the topic some thought. My current thinking and rationale is written=20 > below, I hope we'll arrive at a consensus on this topic this=20 > time...... >=20 > In short, I'm leaning towards not saying anything on discovery=20 > reinstatement in the Implementer's guide, but still open to being=20 > persuaded otherwise. Sorry it's a long note. >=20 > [Options: >=20 > A. TPGTs are always Node-scoped. If Node name isn't specified in the=20 > discovery Login Request PDU, TPGT is meaningless and can't be=20 > inferred=20 > (or inferred to be invalid). >=20 > B. TPGTs are always Node-scoped. If Node name isn't specified in the=20 > discovery Login Request PDU, a special "No-Name" iSCSI Node=20 > is implied.=20 > This No-Name iSCSI Node has its own TPGT numbering space -=20 > one tag for=20 > each physically possible portal group - and thus the TPGT can=20 > be inferred. ] >=20 >=20 > Question 1: > Is it desirable that an initiator precisely know in advance when a new > discovery session might reinstate an existing discovery session (with > the same Network Entity)? >=20 > Yes (based on the plugfest feedback), so let's analyze what=20 > this leads=20 > us to. If I got this wrong, feel free to reset me (especially to Bob=20 > Russell). >=20 > If the answer is no, then the whole discussion is moot (jump=20 > down to the > conclusions). >=20 > Question 2: > If so, how would the initiator deterministically know what reinstates > what? >=20 > Option A: > Assuming a fixed InitiatorName and ISID pair, a new no-named discovery > session will reinstate an old no-named discovery session if the > following is met: > (1) servicing iSCSI Portal (for the new session) is hosted by the > same Network Entity as that of the existing session. >=20 > Option B: > Assuming a fixed InitiatorName and ISID pair, a new no-named discovery > session will reinstate an old no-named discovery session if the > following are met: > (1) servicing iSCSI Portal (for the new session) is hosted by the > same Network Entity as that of the existing session, and, >=20 > (2) TPGT of the servicing iSCSI Portal (for the new session) matches > that of the existing session. >=20 > Question 3: > Can the conditions for each option be met? >=20 > Condition (1) can be met if we assume that the initiator has a > (non-iSCSI) way of discovering that two IP addresses are hosted > by one remote system (i.e. iSCSI Network Entity). >=20 > Condition (2) for realizing Option B however cannot be met=20 > because TPGT > is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the > absence of a node name nor a way to communicate them to the initiator > apriori. Besides, there's a bootstrapping problem in that a discovery > session is needed to find out TPGT associations. >=20 > So I believe condition (2) cannot be met, and thus do not see a way to > support Option.B *given* the desire that the initiator=20 > deterministically > predict session reinstatement in advance (answer to Question.1). >=20 >=20 > To summarize: >=20 > I see four possibilities (in decreasing order of my preference): >=20 > I. We reject the assertion that initiator should be able to > deterministically predict session reinstatement. So say > nothing about this topic in the Implementer's guide. >=20 > II. We accept the assertion. So mandate Option A in Implementer's > guide. >=20 > III.We "semi-accept" the assertion by saying that the initiator cannot > predict reinstatement in advance but will know why a=20 > reinstatement > happened post-fact (because the new session returned the=20 > same TPGT > as did an existing no-named session). So mandate Option B in > Implementer's guide. >=20 > IV. We reject the assertion. Specify both Option A and=20 > Option B in the > Implementer's guide. And leave it to implementer's discretion. >=20 > I am personally fine with either I or II but not motivated to=20 > go to III > because it does not satisfy the "predict in advance" desire even > while it requires enhancements/changes to RFC 3720 (and by=20 > extension, to > some existing implementations): > a) allow a No-Name target node (i.e. a node that maps 1-to-1 > with Network Entity) > b) explicitly allow a TPGT numbering space for a No-Name target > c) mandate returning TPGT on no-named discovery sessions. > d) deal with second-order questions such as: shouldn't the > No-Name target information be returned in SendTargets response? > how about target port names for No-Name target node? .... >=20 > The net is that I see very little ROI in III. >=20 > I again see little ROI in IV. > --=20 > Mallikarjun >=20 > Mallikarjun Chadalapaka > Networked Storage Architecture > StorageWorks Division > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm [at] rose.hp.com >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips