RE: iSCSI: Negotiating a parameter more than once

["THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>]

Julian,

 

Whether the discovery session is long lived or not isn't really relevant to whether SendTargets can be offerred more than once per a negotiation _sequence_ since there can be multiple negotiation sequences during a discovery session. Keeping a discovery session open and sending SendTargets multiple times in a discovery session is specifically allowed (Appendix D page 249 just before the examples). The draft is silent on whether that is allowed within the same negotiation sequence.

 

IMO, since it is simple for the initiator to start a new negotiation sequence by sending a Text Request after the last sequence finishes, there isn't any reason to complicate things by allowing multiple SendTargets within a sequence.

 

Regards,

Pat

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, June 19, 2002 11:58 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: ips@ece.cmu.edu; Julo-Actcom; owner-ips@ece.cmu.edu; 'THALER,PAT (A-Roseville,ex1)'
Subject: RE: iSCSI: Negotiating a parameter more than once

Marjorie, 

We discussed this repeatedly in the past 
and I recall that except the dissenting voice of Mark Bakke the agreement was 
that long-lived discovery sessions are not considered useful. 

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com> Sent by: owner-ips@ece.cmu.edu 06/19/2002 09:31 PM Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

To:        "'THALER,PAT (A-Roseville,ex1)'" <pat_thaler@agilent.com>, Julo-Actcom <Julian_Satran@actcom.net.il>, ips@ece.cmu.edu         cc:                 Subject:        RE: iSCSI: Negotiating a parameter more than once

In the context of the two keys that are valid during FFP, 
neither of these suggested edits to that paragraph make sense.  Currently, 
there is no "negotiation" key that's valid in FFP, and the "declarative" keys 
that are valid, - SendTargets and MaxPDUDataLength *can* validly be repeated. 
 If an initiator opens a discovery session, it may keep it open, and it may 
repeat SendTargets requests as it deems necessary to keep it's target 
information up to date.  In the course of a SendTargets response, the 
target validly repeats certain keys.  The MaxPDUDataLength key can be sent 
by the initiator as often as the PMTU changes. 
  
Why not just delete this paragraph?  In the future if 
there are keys added that are valid during FFP, the RFC that specifies those 
keys can specify whether or not they can be "renegotiated". 
  
Marjorie Krueger
Networked Storage Architecture
Networked Storage 
Solutions Org.
Hewlett-Packard

-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) 
[mailto:pat_thaler@agilent.com]
Sent: Wednesday, June 19, 2002 10:19 
AM
To: Julo-Actcom; ips@ece.cmu.edu
Subject: RE: iSCSI: 
Negotiating a parameter more than once

Julian, 
  
If declarations should not be repeated (except for 
those where it is explicitly allowed), then it should be "negotiate or declare" 
because "negotiate" doesn't cover declarations. Alternatively, one could add an 
explicit definition that "Negotiate" includes both declarations and 
negotiations. Secondly, SendTargets is not a valid example for login as it is 
FFPO. I think the only parameter explicitly allowed to be duplicated during 
Login is TargetAddress (when returned as a result of a redirect). Furthermore, I 
can not find any explicit statement that SendTargets may be repeated during a 
FFP negotiation sequence. Only TargetName and TargetAddress have explicit text 
allowing them to be repeated (in Appendix B for both and in the description of 
redirection for LoginResponse for TargetAddress). 
  
Therefore, I suggest: 
For 4.3: 
Neither the initiator nor the target 
should attempt to declare or negotiate a parameter more than once during login 
except for responses to specific keys that explicitly allow repeated key 
declarations (e.g. TargetAddress). If detected by the target this MUST result in 
a Login reject (initiator error). The initiator MUST drop the connection 
  
For 4.4:
Neither the initiator nor the target should attempt to 
declare or negotiate a parameter more than once during any negotiation sequence 
without an intervening reset except for responses to specific keys that 
explicitly allow repeated key declarations (e.g. TargetAddress). If detected by 
the target this MUST result in a Reject with a reason of "protocol error". The 
initiator MUST reset the negotiation as outlined above. 
  
Pat 
-----Original 
Message-----
From: Julo-Actcom 
[mailto:Julian_Satran@actcom.net.il]
Sent: Tuesday, June 18, 2002 
10:12 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Negotiating 
a parameter more than once

Pat, 
  
4.3 and 4.4 cover two diferent phases. 
Parameters should not be negotiated or declared twice. 
  
I think 
that you refer to the responses to SendTargets - those contain more than an 
instance of the declarations and have to outlined. 
  
How 
about the following text in 4.4:

Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection.

and in 4.4:

Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above.

Julo

---

• To: Julian_Satran@il.ibm.com
• Subject: iSCSI: Negotiating a parameter more than once
• From: pat_thaler@agilent.com
• Date: Mon, 17 Jun 2002 16:18:43 -0600
• Cc: ips@ece.cmu.edu
• Content-Type: text/plain;charset="ISO-8859-1"
• Sender: owner-ips@ece.cmu.edu
  

  ---

  
  Julian,
  
  The following text appears in 4.3 (page 78 just before 4.3.1):
  
  Neither the initiator nor the target should attempt to negotiate a
  parameter more than once during login. If detected by the target this
  MUST result in a Login reject (initiator error). The initiator MUST
  drop the connection.
  
  and nearly the same text in 4.4 (page 85 near the end):
  
  Neither the initiator nor the target should attempt to negotiate a
  parameter more than once during any negotiation sequence without an
  intervening reset. If detected by the target this MUST result in a
  Reject with a reason of "protocol error". The initiator MUST reset
  the negotiation as outlined above.
  
  This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times.
  
  Perhaps the text should be changed to:
  
  Neither the initiator nor the target should attempt to declare or negotiate a
  parameter other than TargetName, TargetAlias or TargetAddress more than once....
  
  Regards,
  Pat
  
  

  ---

  • Prev by Date: RE: iSCSI: use of Text/Login with no data segment
  • Next by Date: RE: iSCSI: Negotiating a parameter more than once
  • Prev by thread: iSCSI 0.13 vs. iSCSI Plugfest
  • Next by thread: RE: iSCSI: Negotiating a parameter more than once
  • Index(es):
    • Date
    • Thread