Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: from osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h4OHTx325376 for ; Sat, 24 May 2003 13:29:59 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix, from userid 953) id 24F6184; Sat, 24 May 2003 13:29:59 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by osgood.ece.cmu.edu (Postfix) with ESMTP id 65E0F8C; Sat, 24 May 2003 13:29:55 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix) id 8941F89DD; Sat, 24 May 2003 13:29:38 -0400 (EDT) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by sos.ece.cmu.edu (Postfix) with ESMTP id 789B589DC for ; Sat, 24 May 2003 13:29:38 -0400 (EDT) Received: by bache.ece.cmu.edu (Postfix) id 5154A68; Sat, 24 May 2003 13:29:38 -0400 (EDT) Received: by bache.ece.cmu.edu (Postfix, from userid 953) id 3072481; Sat, 24 May 2003 13:29:38 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by bache.ece.cmu.edu (Postfix) with ESMTP id EFA5D68 for ; Sat, 24 May 2003 13:29:33 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix, from userid 363) id C607F89DE; Sat, 24 May 2003 13:29:33 -0400 (EDT) X-Original-To: ips@sos.ece.cmu.edu Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by sos.ece.cmu.edu (Postfix) with ESMTP id 58BC989DC for ; Sat, 24 May 2003 13:29:32 -0400 (EDT) Received: by bache.ece.cmu.edu (Postfix) id E065E68; Sat, 24 May 2003 13:29:31 -0400 (EDT) Delivered-To: ips@ece.cmu.edu Received: by bache.ece.cmu.edu (Postfix, from userid 953) id AD79B84; Sat, 24 May 2003 13:29:31 -0400 (EDT) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by bache.ece.cmu.edu (Postfix) with ESMTP id C423B68 for ; Sat, 24 May 2003 13:29:21 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4OHTJCi030542; Sat, 24 May 2003 19:29:19 +0200 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4OHTI4I240346; Sat, 24 May 2003 19:29:18 +0200 In-Reply-To: To: Eddy Quicksall Cc: "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" Subject: Re: FW: iSCSI: TargetPortalGroupTag for discovery MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 From: "Julian Satran" Message-ID: Date: Sat, 24 May 2003 20:29:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 24/05/2003 20:29:18, Serialize complete at 24/05/2003 20:29:18 Content-Type: multipart/alternative; boundary="=_alternative 005F738CC2256D30_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk X-Spam-Status: No, hits=-8.4 required=5.0 tests=BAYES_01,HTML_30_40,HTML_FONT_COLOR_BLUE, HTML_FONT_FACE_ODD,IN_REP_TO version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) This is a multipart message in MIME format. --=_alternative 005F738CC2256D30_= Content-Type: text/plain; charset="US-ASCII" Eddy, I think Marjorie is right - you SHOULD report TargetPortalGroup during a normal session to enable initiators to sense a configuration change if there was one. I will check the text for the typo - thanks - and wording. I think you may ignore it for discovery sessions. Regards, Julo Eddy Quicksall 24/05/03 01:31 To Julian Satran/Haifa/IBM@IBMIL, "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" cc Subject FW: iSCSI: TargetPortalGroupTag for discovery Julian, Can you comment on this? I would like to not have to report the TargetPortalGroupTag during a discovery session. Eddy -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, May 23, 2003 4:23 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Ips@Ece.Cmu.Edu (ips@ece.cmu.edu) Subject: RE: iSCSI: TargetPortalGroupTag for discovery The definition of SSID says this: The TargetPortalGroupTag key must also be returned the target as a confimation (typo) during connection establishment. Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie.krueger@hp.com] Sent: Friday, May 23, 2003 4:16 PM To: 'Eddy Quicksall'; Ips@Ece.Cmu.Edu (ips@ece.cmu.edu) Subject: RE: iSCSI: TargetPortalGroupTag for discovery I think the wording in the spec says TargetPortalGroupTag should be included in the Login response. It seems that a discovery session where multiple targets are being serviced by the same IP address is a case where TargetPortalGroupTag need not be reported? The intent behind reporting TargetPortalGroupTag is directed towards Full Feature Sessions so that the initiator can verify that it's discovery information is still valid. -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, May 23, 2003 1:03 PM To: Ips@Ece.Cmu.Edu (ips@ece.cmu.edu) Subject: iSCSI: TargetPortalGroupTag for discovery I have a question regarding the determination of the Target Portal Group Tag during a discovery session when the TargetName is not supplied. The TargetPortalGroupTag must be reported in the first Login Response for all session types. But without the TargetName, how does the network entity determine which Target Portal Group Tag to report if two different targets in the network entity are using the same IP Address/TCP Port? Eddy --=_alternative 005F738CC2256D30_= Content-Type: text/html; charset="US-ASCII"
Eddy,

I think Marjorie is right - you SHOULD report TargetPortalGroup during a normal session to enable initiators to sense a configuration change if there was one.
I will check the text for the typo - thanks - and wording.
I think you may ignore it for discovery sessions.

Regards,
Julo



Eddy Quicksall <eddy_quicksall@ivivity.com>

24/05/03 01:31

To
Julian Satran/Haifa/IBM@IBMIL, "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" <ips@ece.cmu.edu>
cc
Subject
FW: iSCSI: TargetPortalGroupTag for discovery





Julian,

 

Can you comment on this?

 

I would like to not have to report the TargetPortalGroupTag during a discovery session.

 

Eddy

 

-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Friday, May 23, 2003 4:23 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)
Subject: RE: iSCSI: TargetPortalGroupTag for discovery

 

The definition of SSID says this:

 

The TargetPortalGroupTag key must also be returned

the target as a confimation (typo) during connection establishment.

 

 

Eddy

 

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie.krueger@hp.com]
Sent: Friday, May 23, 2003 4:16 PM
To: 'Eddy Quicksall'; Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)
Subject: RE: iSCSI: TargetPortalGroupTag for discovery

 

I think the wording in the spec says TargetPortalGroupTag should be included in the Login response.  It seems that a discovery session where multiple targets are being serviced by the same IP address is a case where TargetPortalGroupTag need not be reported?  The intent behind reporting TargetPortalGroupTag is directed towards Full Feature Sessions so that the initiator can verify that it's discovery information is still valid.
-----Original Message-----
From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
Sent: Friday, May 23, 2003 1:03 PM
To: Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)
Subject: iSCSI: TargetPortalGroupTag for discovery

I have a question regarding the determination of the Target Portal Group Tag during a discovery session when the TargetName is not supplied.

 

The TargetPortalGroupTag must be reported in the first Login Response for all session types. But without the TargetName, how does the network entity determine which Target Portal Group Tag to report if two different targets in the network entity are using the same IP Address/TCP Port?

 

Eddy

 

--=_alternative 005F738CC2256D30_=--