Subject: Re: [Ips] iSCSI cmd ordering and tagged task

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 20 Nov 2003 12:31:33 -0800

Nick,

 > Frankly, I will continue to advicate the point that only
 > ErrorRecoveryLevel=1 and above implementations will be allowed use
 > multiple connection sessions.  Any iSCSI target supporting multiple
 > connection sessions in a ErrorRecoveryLevel=0 implemenation is broken

Why?

The iSCSI semantics wrt multi-connection sessions are
always true (really relevant based on the operational value
of the MaxConnections key), not tied to the operational
ErrorRecoveryLevel key.

M

Nicholas A. Bellinger wrote:

> Dan,
> 
> 	Session wide ordering is a requirement for even single connection
> ErrorRecoveryLevel=0 implementations.  Please see section 3.2.2.1 for
> the MUST requirement.  Not supporting CmdSN/ExpCmdSN/MaxCmdSN ordering
> requirements is a definate violation of the iSCSI specification in a
> simple ErrorRecoveryLevel=0 implementation,  let alone a multiple
> connection ErrorRecoveryLevel=1 and above implementation.
> 
> One of the key goals of RFC 3347 and the iSCSI draft is to allow iSCSI
> vendors to create interoptable high speed implemenations.  Leaving out
> basic parts of the specification to avoid doing the necessary work to
> make the implementation is question interoptable with industry standard
> implemenations is a bad position to put ones self into.
> 
> Frankly, I will continue to advicate the point that only
> ErrorRecoveryLevel=1 and above implementations will be allowed use
> multiple connection sessions.  Any iSCSI target supporting multiple
> connection sessions in a ErrorRecoveryLevel=0 implemenation is broken
> IMHO and does so to support broken iSCSI ErrorRecoveryLevel=0 initiator
> implemenations and vendors who believe they can get away with only doing
> parts of ErrorRecoveryLevel=1 without doing a complete
> ErrorRecoveryLevel=1 implementation.
> 
> Negoitating the ErrorRecoveryLevel=1 key during the leading connection
> of a full feature phase iSCSI login means the supporting the nine (9)
> requirements of within-command and within-connection recovery from
> sections 6.1.4.1 and 6.1.4.2,  negoitating the ErrorRecoveryLevel=1 key
> without implementing these features is a clear violation of the
> specification.
> 
> In order to support the nine (9) requirements of ErrorRecoveryLevel=1
> means supporting Fixed Interval Markers or some other framing mechnisim
> to recover from header digest failures where the offset to the next
> iSCSI Opcode cannot be reliably determined. (See section 6.1.4.1,
> Initiator and Target case C, and section 3.2.8)  Also in the
> within-command recovery cases from section 6.1.4.1, DataPDUInOrder=No
> and DataSequenceInOrder=No cases must also be considered.
> 
> Thanks!
> 

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips