Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types

From: "John Hufferd" <[email-masked]>
Date: Sun, 7 Jul 2002 10:44:28 -0700

Let me add to this, I think I remember that someone might have special
x-keys they want to support.

Also, I remember the use of NOP-In commands were needed for long lasting
sessions, hence the use of MAY, if the target did not want to support long
lasting sessions.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

"Ayman Ghanem" <[email-masked]>@ece.cmu.edu on 07/07/2002 09:40:33 AM

Sent by:    [email-masked]

To:    <[email-masked]>
cc:
Subject:    RE: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types

I prefer leaving this as "MAY" for implementations that want to support new
device notifications. There was a discussion on whether discovery sessions
should be long-lived or not. Using MAY allows both without breaking any
thing.

-Ayman

> [T.6] 2.3  iSCSI Session Types
>
>       b)  Discovery-session - a session opened only for target discov-
>       ery; the target MAY accept only text requests with the SendTar-
>       gets key and a logout request with reason "close the session".
>
> Change "MAY" to "MUST", and say that other requests MUST be rejected.
>

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 9 Jul 2002 08:40:09 +0300

David,

The original MAY was perfectly appropriate and so is the MUST.
If you say that you have targets that MAY not support anything else than 
.. the an initiator attempting to use anything else
would do it at its own risk.
Your preference for MUST puts an additional mandatory burden to targets to 
CHECK (all targets) that nothing else
is sent.

It is strict where none of us thought that we have to be.

From an initiator POW they are equivalent.
For a target it requires more work.

I would favor the way we where ... but that may be all age related.

Julo

[email-masked]
Sent by: [email-masked]
07/08/2002 05:18 PM
Please respond to Black_David

        To:     [email-masked], [email-masked]
        cc: 
        Subject:        RE: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types

Ayman,

Something needs to be cleaned up here, as the current text appears
to allow all types of iSCSI PDUs on a discovery session.  I didn't
intend to restrict a discovery session to one Send Targets followed
by a logout (i.e., it could be kept open with the initiator periodically
sending a new Send Targets to see if anything has changed), but I
did intend to forbid SCSI commands, task management, etc. on Discovery
sessions.  Is that reasonable, or are there additional types of iSCSI
PDUs that you want to see allowed for new device notifications?

Thanks,
--David

> -----Original Message-----
> From: Ayman Ghanem [mailto:[email-masked]]
> Sent: Sunday, July 07, 2002 12:41 PM
> To: [email-masked]

---

From: [email-masked]
Date: Tue, 9 Jul 2002 02:41:31 -0400

Ayman,

> The issue that came up before was if a discovery session could be kept
open,
> why not allow the initiator and target to send NOPs, and allow the target
to
> send Async messages when new targets become available?
> 
> I don't mean to bring up this issue again at this stage, but using "MAY"
> leaves room for implementations that want to support this. If we allow NOP
> and Async PDUs on a discovery session, then changing "MAY" to "MUST" will
be
> fine.

That would be fine with me as long as we spell out which Async PDUs are used
and what they do - it looks like codes 1 (target requests logout), 3 (target
is closing session) and 4 (target requests negotiation) would be acceptable,
with code 4 having the meaning "please issue a Send Targets" when used on a
discovery session.  The text to specify this needs to be more than just the
single "MUST" in order to avoid applying a "MUST" to long-lived discovery
session support.  Here's an attempt, but it's a bit long and could use
some editing:

On a discovery session, an Initiator:
- MUST NOT issue PDUs other than Send Targets, a logout request to close
	the session, and NOP-Out.
- MAY ignore NOP-In and Async Message PDUs from the target, but MUST NOT
	treat NOP-In and Async Message PDUs with codes 1, 3, and 4 as
errors.
	(Hmm ... ignoring code 1 [request logout] and 3 [target is closing
	session] does not seem like a good idea, although it does work as
	the target can time-out and tear down the session itself).
- MUST treat an Async Message PDU with code 4 (negotiation request) as a
	request to issue a Send Targets command, although the initiator MAY
	ignore the request.
- MUST treat as a protocol error (terminate session), any
	received PDU other than (1) NOP-In, (2) Async Message and (3)
	responses to PDUs issued by the Initiator.

On a discovery session, a Target:
- MUST accept and respond to Send Targets and a logout request to
	close the session.
- MAY ignore NOP-Out PDUs from the initiator, but MUST NOT treat them as
	errors.
- MUST NOT issue PDUs other than NOP-In, Async Message PDUs with codes 1
	(request logout), 3 (announce session closure) and 4 (request
	negotiation), and PDUs required to respond to Send Targets and
	a logout request from the Initiator.
- MUST treat as a protocol error (terminate session), any
	received PDU other than (1) a text PDU containing Send Targets,
	(2) a Logout Request to close the session, and (3) NOP-Out.

My underlying motivation is that if we're going to allow long-lived
discovery sessions, it behooves us to specify how they work sufficiently
for interoperability.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Tue, 9 Jul 2002 02:38:02 -0400

Julian,
 
Your "at its own risk" is an invitation to interoperability problems -
if Discovery sessions are meant to be fixed functionality, then an
Initiator that attempts to exceed that functionality needs to get
told NO - otherwise we're going to see READ commands on Discovery
sessions to get additional configuration information, and then
task management, and ... this neat stuff will only work right
when the same implementation is on both ends of the connection.
 
I have a separate reply to Ayman's message coming that contains
an attempt at requirements text, but it's longer than I would like.
 
Thanks,
--David

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 1:40 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types

David, 

The original MAY was perfectly appropriate and so is the MUST. 
If you say that you have targets that MAY not support anything else than ..
the an initiator attempting to use anything else 
would do it at its own risk. 
Your preference for MUST puts an additional mandatory burden to targets to
CHECK (all targets) that nothing else 
is sent. 

Julo 

	[email-masked] 

07/08/2002 05:18 PM 

Ayman,

Thanks,
--David

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 10 Jul 2002 06:42:52 +0300

You have a good point and it was made before but it was the compromise
reached after a long debate
and I am still opposed to embedded discovery but I can accept it as a
lesser evil if the session is short.

I can agree with MUST but I will resist adding any notification.

It is just the wrong thing to do.

Julo

                      [email-masked]                                                                                                     
                      om                       To:       Julian Satran/Haifa/IBM@IBMIL                                                      
                      Sent by:                 cc:       [email-masked]                                                                    
                      [email-masked]        Subject:  RE: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types                                    
                      .edu                                                                                                                  

                      07/09/2002 09:38                                                                                                      
                      AM                                                                                                                    
                      Please respond to                                                                                                     
                      Black_David                                                                                                           

Julian,

Thanks,
--David

 -----Original Message-----
 From: Julian Satran [mailto:[email-masked]]
 Sent: Tuesday, July 09, 2002 1:40 AM
 To: [email-masked]
 Cc: [email-masked]; [email-masked]; [email-masked]
 Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types

 David,

 Julo

    [email-masked]                                                    
    Sent by:                        To:        [email-masked],          
    [email-masked]   [email-masked]                                
                                    cc:                                    
                                    Subject:        RE: iSCSI: DLB's [T.6] 
    07/08/2002 05:18 PM     2.3  iSCSI Session Types                       
    Please respond to                                                      
    Black_David                                                            

 Ayman,

 Thanks,
 --David

---

From: "Prasenjit Sarkar" <[email-masked]>
Date: Thu, 11 Jul 2002 08:15:38 -0700

I'm not sure what Mark means by "we", but I am opposed to any dynamic
discovery mechanisms for SendTargets because of my belief that these
mechanisms does not belong here. Therefore I vote against Noop and Async
messages,

Sincerely,

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose

                      Mark Bakke                                                                               
                      <[email-masked]        To:       [email-masked]                                   
                      >                        cc:       Julian Satran/Haifa/IBM@IBMIL, [email-masked]        
                      Sent by:                 Subject:  Re: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types       
                      [email-masked]                                                                        
                      .edu                                                                                     

                      07/11/2002 08:21                                                                         
                      AM                                                                                       

Actually, we want to be able to send Async Message and Noop In
from the target, and allow the initiator to send Noop Out, since
these are more in the iSCSI session maintenance category of
messages.

There's definitely no reason to allow Scsi Command / Response,
Task Management Command / Response, Data In/Out, Snack, and
R2T on a discovery session.

--
Mark

[email-masked] wrote:
> Julian
> I don't care - getting to a MUST with a list of allowed PDUs that
> forbids all others from the current MAY that allows everything is
> what matters to me.
>
> At the moment, I've only seen Ayman ask for Async Message to be
> allowed on discovery sessions - does anyone else want to see that
> PDU allowed on discovery sessions?
>
> Thanks,
> --David

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 11 Jul 2002 18:17:12 +0300

I completely disagree - and this is a thing that we debated repeatedly.
I formally ask this to be closed, We don't want the discovery session 
as an alternative discovery mechanism. The IP protocol set has enough 
other (common)
venues for this.

Julo

Mark Bakke <[email-masked]>
Sent by: [email-masked]
07/11/2002 06:21 PM
Please respond to Mark Bakke

        To:     [email-masked]
        cc:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        Subject:        Re: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Nicolson, Alex" <[email-masked]>
Date: Thu, 11 Jul 2002 11:30:00 -0400

I would like to see Async Message supporteed.

Alex Nicolson
Emulex Corporation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 1:01 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI: DLB's [T.6] 2.3 iSCSI Session Types

Julian

Thanks,
--David

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 11 Jul 2002 09:04:55 -0700

I also believe that those extended discovery functions belong in SLP and
iSNS, not in extending the Discovery Session.  The Discovery Session was
intended for the simple lower end iSCSI network, that did not have SLP or
iSNS.  And in that end of the market there is no reason to have long lived
Discovery sessions.  Also this will cause vendors to invent ways to work
with the base discovery session, that were unintended and thus cause
additional problems, and not focus on getting interoperable support for SLP
and iSNS.

Each of our approaches, "discovery sessions", SLP, and iSNS, generally
cover different network markets, and this segmentation is rather easy to
explain.  I would prefer to continue this focus, or we will confuse the
market and ourselves and never be interoperable.

.
.
.
John L. Hufferd

Prasenjit Sarkar/Almaden/IBM@[email-masked] on 07/11/2002 08:15:38 AM

To:    Mark Bakke <[email-masked]>
cc:    [email-masked], [email-masked], Julian Satran/Haifa/IBM@IBMIL,
       [email-masked]
Subject:    Re: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types

Sincerely,

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose

                      Mark Bakke
                      <[email-masked]        To:
                      [email-masked]
                      >                        cc:       Julian
                      Satran/Haifa/IBM@IBMIL, [email-masked]
                      Sent by:                 Subject:  Re: iSCSI: DLB's
                      [T.6] 2.3  iSCSI Session Types
                      [email-masked]
                      .edu

                      07/11/2002 08:21
                      AM

--
Mark

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 11 Jul 2002 09:44:19 -0700

This "voting" is invalid in the absence of technical debate, and this issue
had sufficient debate and was closed long ago - the decision was "no support
for long lived discovery sessions".  It's disturbing that this is brought up
again as if no agreement was reached.  I refer you to the attached email.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard

> From: Kaladhar Voruganti [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2002 7:17 AM
> To: [email-masked]
> Subject: iSCSI: Discovery Session Functionality
> 
> 
> 
> 
> This note describes the Naming and Discovery teams's current 
> resolution regarding the use of
> NOPs and Asynch messages in the discovery session:
> 
> There was no agreement on the need or appropriateness of this requirement.
> So the general concensus from the Naming and Discovery team, was not to
> add NOPs or any other commands to the Discovery Session.  It will be left
> as only SendTargets can be sent during the Discovery Session.
> 
> Kaladhar Voruganti

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 11 Jul 2002 10:31:23 -0700

Marjorie is, in my opinion, correct!

.
.
.
John L. Hufferd

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>@ece.cmu.edu
on 07/11/2002 09:44:19 AM

To:    "Ips Reflector (E-mail)" <[email-masked]>
cc:
Subject:    RE: iSCSI: DLB's [T.6] 2.3  iSCSI Session Types

This "voting" is invalid in the absence of technical debate, and this issue
had sufficient debate and was closed long ago - the decision was "no
support
for long lived discovery sessions".  It's disturbing that this is brought
up
again as if no agreement was reached.  I refer you to the attached email.

Marjorie Krueger